Messages in this thread | | | Date | Tue, 30 Nov 2004 15:29:58 -0800 | From | Matt Mackall <> | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |