Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

Linus Torvalds
2004-12-14T15:49:34Z

On Tue, 14 Dec 2004, Werner Almesberger wrote:
>
> Hmm, so you're predicting problems if user space includes something
> that uses uint32_t ? Wouldn't either of these work (descriptive file
> names for clarity):
>
> 1) include/linux-user/foo.h:
> #include <stdint.h>
> #include <linux-kernel-and-user-common/foo.h>

No. Because when you include <sys/ioctl.h> (which includes the
<linux-user/foo.h>, the POSIX/SuS/whatever namespace rules say that YOU
MUST NOT pollute the namespace with the names from stdint.h.

The user is supposed to see "int32_t" and friends _only_ if the user
himself includes <stdint.h> or one of the very specific headers that is
documented by the standard to include it.

Trust me. We are NOT going to use <stdint.h> in the kernel.

This is a common issue with namespace pollution. For example, this program
is perfectly valid afaik (well, except for being _stupid_, but that's
another issue):

#include <stdio.h>

const char *int32_t(int i)
{
return i ? "non-zero" : "zero";
}

int main(int argc, char **argv)
{
return printf("argc is %s\n", int32_t(argc));
}

Get the picture? The user may _use_ names that are defined for the
standard - like "strlen()" or "uint32_t" - for his own nefarious purposes,
because they are _only_ defined if you include the right header files.

And trust me, the rules are really arcane. Not only do you have several
standards, and several versions, you have various local rules too, ie gcc
and glibc make up their own rules about things that depend on compiler
flags etc.

And that is why a kernel header file must not define them, and by
implication, cannot use these names.

Because the whole _point_ of having kernel header files that can be used
in user-space is that they are helpers for things like <sys/ioctl.h> etc,
that would just copy them.

If we are going to pollute the user-visible namespace in random ways, the
whole discussion is pointless. At that point, glibc (or any other libc)
can't use those API headers anyway.

Remember: the _biggest_ reason to make kernel headers available is not to
user programs that want them, but to libc and friends.

Linus