Messages in this thread | | | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ | From | Krzysztof Halasa <> | Date | Sat, 27 Nov 2004 17:12:38 +0100 |
| |
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/
| |