Re: State of userland headers

From: Kyle Moffett
Date: Sat Mar 25 2006 - 01:31:22 EST


On Mar 24, 2006, at 20:36:15, Jeff Dike wrote:
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. 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.

So perhaps could we define an informal subset of the kernel code that works in both userspace and kernel-space and put it in include/libk? Stuff like linked lists, spinlocks (depends on arch, may not be supported), etc could be in linux/libk and linux/include/libk or similar, and then from there included into linux/include/linux/ list.h, etc, as well as into the UML files that need it. Since the provider and user would both be the Linux kernel, I see no issues with trying to provide a stable interface of any kind, especially if we document it as "PRIVATE - FOR KERNEL USE ONLY!!!" with big warning signs. As a nice bonus, this would make it possible to implement some user-space unit tests of various pieces.

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/