Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Linus Torvalds <torvalds@osdl.org>]

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