Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Linus Torvalds]

On Tue, 30 Nov 2004, David Howells wrote:
> 
> > But in general, I do kind of like the explicit marking. The same way we 
> > explicitly mark the functions inside the kernel that we expose to modules, 
> > we could try to mark the data structures and values that we expose to user 
> > space. That tends to "work".
> 
> That gets trickier when it comes to #defines, I think.
> 
> Do you really object that much to splitting the header files as I proposed?

I object sternuously to your "the header files". If you can't even say 
_which_ header file, I'm not interested.

If you can say "these X header files have this specific problem Y, and if 
we move part Z into a common area A, we'd solve it because B", that's a 
different matter.

See what I'm saying? Whole-sale "move things around because we want to" 
I'm not interested in. Specific problems, yes.

> Personally, I'd prefer us to move to using standard C99 types in lieu of u32
> and co at least for the interface to userspace because they are just that:
> standard.

No. I told you why it cannot and MUST NOT be done. Repeat after me:

	WE MUST NOT POLLUTE THE NAMESPACE!

There are many cases where including a header file means you want the
structure, but it does _not_ mean that you can expose totally unrelated 
types, even if those types happen to be used as part of the structure. See 
what I'm saying?

In contrast, __u8/__u16/__xxx are explicitly defined by the relevant 
standards to be "system name space", and that is _exactly_ why we don't 
use the standard namespaces.

And the fact is, the rules for _when_ you export _which_ standard types
are just too damn hard, and more importantly, they are not something that
the kernel headers should even be deciding. They depend on glibc internal
things like __USE_BSD etc, and they depend on which standard you compile
for, and sometimes even on which _version_ of the standard you compile
for.

I will not have that mess in the kernel. Which means that we do _not_ 
export any of the standard names. Which means that we can't _use_ any of 
them. End of story.

		Linus
-
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/