Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Alexandre Oliva <aoliva@redhat.com>]

On Nov 25, 2004, Matthew Wilcox <matthew@wil.cx> wrote:

> On Thu, Nov 25, 2004 at 04:20:06PM -0200, Alexandre Oliva wrote:
>> This means these headers shouldn't reference each other as
>> linux/user/something.h, but rather as linux/something.h, such that
>> they still work when installed in /usr/include/linux.  This may
>> require headers include/linux/something.h to include
>> linux/user/something.h, but that's already part of the proposal.

> That's going to take severe brain-ache to get right ... and worse,
> keep right.  These headers aren't going to get tested outside the kernel
> tree often.  So we'll have missing includes and files that only work if
> the <linux/> they're including is a kernel one rather than a user one.

How about moving the internals (i.e., what's not to be exported to
userland) from linux and asm elsewhere, then?

Sure, it means significantly more churn in the kernel, but there's
going to be a lot of moving stuff around one way or the other.

While at that, we could also split what's kernel internal for real and
what's to be visible to external kernel modules as well.  So we'd have
3 layers of headers, instead of two.  I'm not sure this actually makes
any sense though, since there might be lots of dependencies of headers
for modules on internal headers.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}