Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[H. Peter Anvin]

Followup to:  <A697CF5A-4267-11D9-8DB8-000393ACC76E@xxxxxxx>
By author:    Kyle Moffett <mrmacman_g4@xxxxxxx>
In newsgroup: linux.dev.kernel
>
> On Nov 29, 2004, at 15:01, H. Peter Anvin wrote:
> > Most people seem to have suggested include/linux-abi for this; I would
> > personally prefer include/linux-abi/arch for the second.
> 
> It seems like there are two ways to adjust the headers.  We could move
> the private headers to a new directory (include/kernel?), or we could 
> move
> the public headers to a new directory (include/linux-abi?).  I am 
> willing to
> work on some simple and trivial patches to begin doing either one, if we
> can reach an agreement as to which one is preferrable (and what to call
> the new directory.)
> 

If we can preserve compatibility, moving the private headers to a
separate place makes sense.  However, preserving compatibility is not
a good thing, because a lot of the brokenness is in how things are
exported.  Thus, you want libc to be able to have a linux/* wrapper
for backwards compatibility.

My first choice would be to put the ABI headers in linux/abi.

> > Good, except your "struct winsize" is bad; you're stepping on
> > namespace which belongs to userspace.  Since we can't use typedefs on
> > struct tags, I suggest:
> >
> > struct __kstruct_winsize {
> >        /* ... */
> > };
> >
> > .. and userspace can do:
> >
> > #define __kstruct_winsize winsize
> 
> My initial suggestion would be to leave the types as-is, primarily for
> the reasons in Linus' earlier email, but also for simplicity and to
> prevent inadvertent breakage.

True; I hadn't considered the weirdness of the namespace pollution
issue.  However, the issue with struct tags remain.

Note also that not all ABI issues can be well-described in C headers,
and certainly not the way it currently is.  Syscall numbers and ioctl
APIs are examples there (I do some hideously ugly hacks in klibc to
try to auto-derive as much of the ABI as possible; this is part of
making klibc very easy to port to new architectures and keeps
maintenance in one place.)  However, cleaning up the headers is a
major step forward.

> >>  (3) Remove all #if(n)def __KERNEL__ clauses.
> >>
> >>  (4) Remove the -D__KERNEL__ from the master kernel Makefile.
> >
> > Bad!  There is code in the kernel which can compile in userspace for
> > testing.  This is highly valuable and should be kept.
> 
> I would propose that if we decide to move the public headers instead of
> the internal kernel headers, we autogenerate headers for installation
> that have a #warning wrapper if __KERNEL__ isn't defined.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/