This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
- From: David Woodhouse <dwmw2 at infradead dot org>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Matthew Wilcox <matthew at wil dot cx>, David Howells <dhowells at redhat dot com>, torvalds at osdl dot org, hch at infradead dot org, linux-kernel at vger dot kernel dot org, libc-alpha at sources dot redhat dot com
- Date: Fri, 26 Nov 2004 11:53:23 +0000
- Subject: Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
- References: <19865.1101395592@redhat.com> <orvfbtzt7t.fsf@livre.redhat.lsd.ic.unicamp.br> <20041125210137.GD2849@parcelfarce.linux.theplanet.co.uk> <ory8goygpr.fsf@livre.redhat.lsd.ic.unicamp.br>
On Fri, 2004-11-26 at 09:47 -0200, Alexandre Oliva wrote:
> 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.
Not really. The kernel code was what was _allowed_ to be using those
headers with those names in the first place; it was userspace which
shouldn't necessarily have been doing so.
> 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.
All modules will be entirely dependent on the full set of kernel
headers. Let's not go there.
--
dwmw2