lkml.org 
[lkml]   [2004]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
From
Date
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
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.171 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site