Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Krzysztof Halasa <khc@pm.waw.pl>]

Alexandre Oliva <aoliva@redhat.com> writes:

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

That's what I proposed several {months,weeks} ago. From a technical
point of view it seems like a superior solution:

- /usr/include/{linux,asm} -> /usr/src/linux/include/{linux,asm} = no
  problems with kernel and userspace includes.
- while Linux is quite a big program, it is _one_ program = no need to
  patch the whole universe, only the kernel would need changing
  (of course broken userspace code would need fixing, but that's
  due to their brokeness and not due to the change).

> 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.

No doubt. Still, quite simple automatic operation, we've seen much larger
patches.

API backward-compatibility (including C libs) is IMHO much more
important than just some kernel patch size (I realize ABI compatibility
would be preserved in all cases).

And we can do it anytime - no need for waiting for some libc change,
no need for waiting for "2.7/2.8".

> 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.

Can't see benefits.
-- 
Krzysztof Halasa