Re: Simple header cleanups

[Kyle Moffett]

On Apr 28, 2006, at 11:37:03, David Woodhouse wrote:
> On Fri, 2006-04-28 at 17:32 +0200, Jan Engelhardt wrote:
> > Sounds like they want it BSD-style. Do they realize that?  New  
> > release, new headers, making it necessary to recompile every app,  
> > because a struct could have changed. That'd seriously impact  
> > compatibility.
>
> Utter crap.
>
> We don't _change_ any of the structs which would be exposed in such  
> files (i.e. the structs which should be outside the #ifdef  
> __KERNEL__ at the moment, because that would mean we break  
> userspace binary compatibility from kernel to kernel.
>
> We absolutely do _NOT_ want to go there. We're talking about  
> cleaning up the existing mess, not starting a crack habit.

Example:  Say the proposed utsname virtualization gets a new clone  
flag (CLONE_NEWUTSNAME).  Old headers would obviously not include the  
CLONE_NEWUTSNAME define.  If you want to compile a glibc that uses  
CLONE_NEWUTSNAME, you need to build it against a set of the "kabi  
headers" from a version of the kernel that includes the feature.  The  
resulting glibc will _run_ on any kernel; if you call clone 
(CLONE_NEWUTSNAME) on an older kernel it would return EINVAL but work  
otherwise.  A glibc that does *not* use CLONE_NEWUTSNAME would build  
an identical binary with older versions and newer versions.  This is  
_exactly_ the way things work now, except there is no outside llh  
project, it's all stored in the kernel tree.

Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/