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

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!

--- Harrison