Re: State of userland headers

From: Kyle Moffett
Date: Sat Mar 25 2006 - 01:45:52 EST


On Mar 24, 2006, at 18:01:00, Randy.Dunlap wrote:
Kyle,
Do you have (recorded) or recall any constraints or requirements on this $subject from Linus or Andrew or others? I mean just basic big items, like "thou shalt not mix foo and bar".

I'm just looking for the basic parameters of this task.

Well, to a large extent he's actually wisely kind of stayed out of the flamewars :-D I'm guessing he's hoping that we'll figure something acceptable out on our own and send him patches without him having to think about it much. He has said this, though:
On the bigger question of what to do with kernel headers in general, let's just make one thing clear: the kernel headers are for the kernel, and big and painful re-organizations that don't help _existing_ user space are not going to happen.

He's also said this:
On Tue, 30 Nov 2004, Alexandre Oliva wrote:
Then maybe this is the fundamental problem. As long as the kernel doesn't recognize that an ABI is a contract, rather than an imposition, kernel developers won't care.

That's a silly analogy. Worse, it's a very flawed analogy.

If you want to use a legal analogy, the ABI is not a contract, it's a public _license_.

Why? A contract is something that you cannot change unilaterally. Clearly the kernel _can_ and will change the ABI without asking every existing program for permission.

In a license, you can always just _expand_ the license eventually. Maybe you originally licensed for "fly-fishing for trout", and later you can expand that license to say "you can also catch crawfish" without impacting your existing licensees.

And exactly as with an ABI, the only thing you can't do is _remove_ rights without getting into trouble.

So get your analogies straight. The kernel ABI is _not_ a contract.

My hope for this is that we can start doing _little_ and clearly obvious changes that clean up header files. Basically a lot of the __KERNEL__ definitions need janitorial work. Either they need to be removed or they need to be put in the right places. Also it seems like there's a lot of duplication between architectures; for one example look at all the varieties of FD_SET code in the different linux/include/asm-*/posix_types.h files. That's one of the areas I'm trying to clean up into a single linux/fdset.h included from the pertinent files. Notice how the file forcibly overrides GLIBC; I think if we can define it as __KABI_FD* and only define the non- prefixed version in __KERNEL__, then we can provide something that GLIBC and klibc can get for free, without having to figure out their own bitmaps. Likewise some of the user-accessible types are uniform across architectures, and others are haphazardly arrayed, some to be compatible with other OSes on that architecture, others just because that's what the arch they copied from used. I'm hoping if I can get enough small patches flowing, others will join in too and the process will go easier.

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/