Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

Krzysztof Halasa
2004-12-05T00:08:11Z

Matt Mackall <mpm@selenic.com> writes:

> It's my opinion that it will eventually be deemed beneficial to
> separate out everything that has a legitimate reason to be used by
> userspace.

That's quite obvious and the whole thread is all about just that.

> But I'm not suggesting getting there in one go,

As this is impossible, given du -s /usr/src/linux/include/*.

> what I'm
> suggesting is how to get there incrementally. To rehash:
>
> 1. create include/user and friends
> 2. when we run across a troublesome ABI definition:
> create include/user/foo.h and move the definition there
> make sure include/linux/foo.h includes it
> userspace and kernel compile as before
> send a patch

What _is_ a "troublesome ABI definition" and who would qualify it
as such?

> 3. repeat step 2 as often as useful

Who would do that?

> 4. add new user ABI always to include/user/

Who would watch that? How do you differentiate between a user API/ABI
and an internal kernel API, if you don't know the code in question
at all?

> 5. if at some point we find that all of userspace builds from
> include/user/ without reference to include/linux/,

How can we find that? Compiling the Fedora Code 7 would not be enough.

> 7. drop any superfluous include/linux -> include/user includes (there
> shouldn't be many)

Why not? Kernel "private" headers can and must include ABI headers
as the private .c files do.

This won't work. include/user won't work either. There can't be any
"transition periods" nor "instant switchovers".

I can see only one way to solve the problem - gradually, without
"transition periods" etc.

1. We leave existing include/linux and include/asm (and possibly
asm-generic etc) in place.
2. A new directory(ies) such as include/kernel (internal kernel headers)
is created.
3. Code authors, who (I hope) know their code move the things they
know are kernel-internal to the new directory(ies).
4. Userspace is explicitly forbidden to include anything in the new
directory. We can even use some #ifndef __KERNEL__ #error user
breakage as a tip.

In a year or two we can probably begin hunting remnants of the
internals in include/linux and include/asm.

We can now consider anything in include/{linux,asm} which prevents
userspace compilation etc. a bug. But bugs must be fixed by people
who know how to fix them correctly.
--
Krzysztof Halasa