[lkml]   [2004]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
Followup to:  <>
By author: Kyle Moffett <>
In newsgroup:
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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