Re: State of userland headers

[Jeff Dike <jdike@addtoit.com>]

On Fri, Mar 24, 2006 at 05:46:27PM -0500, Kyle Moffett wrote:
> 4)  UML runs into a lot of problems when glibc's headers and the  
> native kernel headers headers conflict.

> UML has other issues with conflicts between the native kernel headers  
> and the GLIBC-provided stubs.  It's been mentioned on the prior  
> threads about this topic that this sort of system would ease most of  
> the issues that UML runs into.

Actually, this isn't quite the same as what UML hits.  I have an
amicable solution (with some warts) to the glibc/kernel header
conflicts - files build against either glibc headers or kernel
headers, but never both.  

The warts are where I pass information between those two sets of files
that could be interpretted differently on either side, but aren't
because both sides are Linux.  For example, I freely pass errno values
across that interface in the hope that the glibc headers and the
kernel headers agree on what they mean. 

My problem with the kernel headers is that they are a mixture of
things that are usable in userspace and things that aren't.  This is
closely related, but not identical to, things which are part of the
ABI and things which aren't.

For example, the kernel locks are quite usable in userspace, but you
would never make them part of the ABI.

So, a set of KABI headers would likely make UML's headers cleaner, by
avoiding copying arch headers and using various nasty tricks to
disable objectionable pieces of headers which I steal from the arch.

So what I really want is a superset of the KABI headers, but the KABI
will give me most of what I want.

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