Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
From: Matt Mackall
Date: Tue Nov 30 2004 - 18:38:27 EST
On Tue, Nov 30, 2004 at 02:55:00PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 30 Nov 2004, Matt Mackall wrote:
> >
> > So we follow dhowell's plan with the following additions:
>
> No.
>
> We do _not_ move stuff over that is questionable.
Umm. I don't think you even read what I wrote.
> I thought that was clear by now. The rules are:
> - we only move things that _have_ to move
Yes. And when we move a definition from linux/foo.h to user/foo.h, we include
them from linux/foo.h..
> - we don't break existing programs, and no "but they are broken already"
> is not an excuse.
..which prevents userland breakage during the transition (and is generally what
you want in the kernel anyway).
> - we only move things where that _particular_ move can be shown to be
> beneficial.
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. But I'm not suggesting getting there in one go, 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
3. repeat step 2 as often as useful
4. add new user ABI always to include/user/
5. if at some point we find that all of userspace builds from
include/user/ without reference to include/linux/, declare
include/user the canonical ABI
6. drop #define __KERNEL__, etc..
7. drop any superfluous include/linux -> include/user includes (there
shouldn't be many)
--
Mathematics is the supreme nostalgia of our time.
-
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/