Messages in this thread | | | Date | Fri, 24 Mar 2006 20:36:15 -0500 | From | Jeff Dike <> | Subject | Re: State of userland headers |
| |
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/
| |