Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes...

From: Alexander Leidinger <Alexander_at_Leidinger.net>
Date: Fri, 18 Aug 2006 10:30:11 +0200
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 = 72077137
Received 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