Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

[Chuck Silvers <chuq%chuq.com@localhost>]

On Fri, Jul 02, 2010 at 08:55:30AM +1000, matthew green wrote:
> 
> > On Thu, Jul 01, 2010 at 01:32:47AM +0200, Rhialto wrote:
> > > On Wed 30 Jun 2010 at 08:57:44 -0700, Chuck Silvers wrote:
> > > >    - the assembler apparently now uses a different opcode for reloading 
> > > > %gs
> > > >      than it used to, so the check for this instruction in INTRFASTEXIT
> > > >      being the cause of a kernel trap wasn't working.  I fixed the check
> > > >      to match the current generated code.
> > > 
> > > Would it not be necessary for compatibility with older binaries (how
> > > much older??) to check for both cases?
> > 
> > there's no compatibility issue here, the kernel is looking at its own
> > instructions, not an application's.  we require that a kernel be built
> > with the matching toolchain, so there's only one version of the assembler
> > that would matter for a particular kernel binary.
> 
> we shouldn't depend upon GCC/gas versions so heavily IMO.  testing for
> both should be failry easy, right?
> 
> sometimes newer / older toolchain components are useful for various
> reasons.. 


well, I'll still argue that it's not useful to use the wrong toolchain,
but (as we discovered in private mail over the last few days),
sometimes dopey people (like me in this case) use the wrong toolchain
by accident and then get very confused when things don't work right.

the executive summary is that the problem with recognizing faults due to
loading %gs doesn't exist in -current, so I'm going to leave that alone.
I'm going to leave the fix for other existing bug (panic due to bad %cs value)
out of the linux changes as well, but I'll come back to it once the linux
changes are in.

and since no one had any other objections, I'm going to check in
the linux changes this afternoon.

-Chuck