Re: cvs commit: src/sys/compat/linux linux_mib.c linux_mib.h linux_misc.c

On Thu, Jan 11, 2007 at 08:53:48AM +0100, Alexander Leidinger wrote:
> Quoting Jeremie Le Hen <jeremie_at_le-hen.org> (from Wed, 10 Jan 2007  
> 23:58:20 +0100):
> 
> [moving to current_at_]
> 
> >Hi Alexander,
> 
> >Sorry if this has been already discussed in the past, I've certainly
> >missed the thread.
> >
> >Is there any strong reason to not enable 2.6.x emulation by default
> >in the future RELENG_7 ?
> 
> We have FC4 in the linux base port. Fedora Legacy is abandoning it, so  
> no security updates anymore. FC5 and later require a 2.6 kernel, they  
> don't run with a 2.4 kernel. So we need the 2.6 emulation rather  
> sooner than later.
 
this raises an issue about updating the FC4 to FC5 if RELENG_[56] is
not able to use it at all. do we plan to ever MFC the 2.6 stuff?
I dont think its a good idea (its a major change) but then - what
is the policy on updating the linux base port? when the 7.x is widespread
enough?
 
> A reason to not enable the 2.6 emulation currently is: we have  
> showstopper bugs.  Acroread is not working. We have a patch for this,  
> but we are discussing some details (security implications and locking  
> stuff). So far I didn't had time to test the functional change of this  
> patch and don't know if it fixes all issues with acroread or not (I  
> know about several ways if cashing acroread with 2.6, other people  
> know only one way (immediate crash at startup), because I'm the only  
> one with an acroread configuration which allows to start acroread  
> (without specifying a PDF) withhin 2.6 without the above mentioned  
> fix). And there may be some other bugs we didn't stumbled upon yet.  
> Because of the showstopper bug and the fact that the amd64 part is  
> only available in p4 ATM, we didn't had widespread testing of the 2.6  
> emulation.

to complete the list of bugs (alexander mentioned just acroread) we also
have problems with futexes - we dont pass a testing program, there's
a suspicious code (I have a patch for that) and we dont support it on
amd64. the last problem (I am aware of) is that amd64 lacks TLS.

Regarding the futexes kib and me plan to work on this "soon" and I am sure
this will be solved very fast. The amd64 TLS is worse because I dont have
comfortable access to amd64 hw nor I know much about the lowlevel stuff.
I asked jkim for help so I hope this will resolve as well.

> So currently the strong reason to not enable it by default is: major  
> bugs, lack of amd64 support and no widespread testing.

widespread testing cannot be achieved without turning it on by default

> When we fixed the showstopper bug with acroread and don't identify  
> another major bug, I will ask for testing 2.6 on -current to identify  
> the easy to find bugs. After a week or two I will change the default  
> emulation to 2.6 in -current, except we have some showstopper  
> problems. At this point I also hope to have the code for amd64 in the  
> tree.

sounds like a plan to me :) but I dont really think we have to wait for
amd64. The part we need to test is almost 100% MI. The MD parts are setting
up GDT which accounts for a few lines of code (note that most of the new futexes
are MI code). I'd prefer testing only on i386 over no testing at all.

> If 2.6 will be enabled by default in 7.0 has to be determined based  
> upon the feedback then.

I think we will summarize the pros and cons and then decide, switching the
toggle is very easy.

roman