Quoting Astrodog <astrodog_at_gmail.com> (from Thu, 17 Aug 2006 17:56:10 -0500): > On 8/17/06, Divacky Roman <xdivac02_at_stud.fit.vutbr.cz> wrote: >> >> On Thu, Aug 17, 2006 at 08:15:38AM -0700, Julian Elischer wrote: >>> Divacky Roman wrote: >>> >>> >>Anyone with interest in this is free to take care of this, as long as >>> >>they coordinate with the people which work on the current >>> >>infrastructure on emulation_at_ regarding the userland/security stuff and >>> >>the kernel. Until someone stands up and shows results/progress, this >>> >>is scheduled to vanish in the future. >>> >> >>> >> >>> > >>> > >>> >I personally see this 3 possible ways: >>> > >>> >1) leave it as it is (ie. as what will be commited shortly), this means >>> >runtime >>> >checking for osrelease sysctl and behaving according to it >>> > >>> >2) introduce option LINUX_24 or something like that to make this a >> compile >>> >time build >>> > >>> >3) remove the 2.4 completely saying that "if you want 2.4 emulation >>> >downgrade fbsd as well". notice that this is 100% ok because linux >> itself >>> >doesnt support 2.4 emulation on 2.6 kernel. >>> > >>> > >>> >>> I think that would be a great selling point.. especially if two >>> processes could run the different releases at the same time.. >>> "even linux needs vmware to do this..". >> >> this is not hard to implement but remeber that it causes getpid() to be >> quite expensive function. and as netchild said - newer glibc doesnt work >> with >> 2.4 kernel so unless somone is willing to maintain libc for the old >> linux_base >> there wont be any use for this. > > > Would it be possible to maintain 2 sets? Basically, leave the old stuff > avalible, but require some sysctl or compile-time setting to use it... if > no one steps up to maintain it, let it rot. If someone wants to deal with > it... let 'em! Don't think about the kernel part. There are multiple ways of handling it. You could even move the 2.4 code to "linux24" and brandelf only some apps with "Linux24" instead of "Linux". This way you don't need to check every time and you don't need to do a sysctl for the apps in question. The kernel is the easy part. The hard part is the userland stuff. As one of two active people which take care of the linux userland infrastructure in ports I can tell you that we just have the official man power to maintain one linux_base infrastructure. And this doesn't take into account that old linux_base ports which still work with 2.4 but will go away in the future and that the linux distributors don't fix security bugs in old releases (so we have to move on to newer linux binaries and remove the old ones). The person(s) taking care about the linux24 stuff would have to create binary packages with fixes for this himself. Bye, Alexander. -- A political man can have as his aim the realization of freedom, but he has no means to realize it other than through violence. -- Jean Paul Sartre http://www.Leidinger.net Alexander _at_ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild _at_ FreeBSD.org : PGP ID = 72077137Received on Fri Aug 18 2006 - 06:30:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC