Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Krzysztof Halasa]

Matt Mackall <mpm@xxxxxxxxxxx> 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
-
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/