Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Horst von Brand <vonbrand@inf.utfsm.cl>]

Werner Almesberger <wa@almesberger.net> said:
> Linus Torvalds wrote:
> > 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.

[...]

> Therefore, stdint.h types would mainly be used with new interfaces,
> or in intermediate definitions which are not themselves part of the
> interface. Of course, the latter would have to consider pollution
> issues.

They _can't_ show up in interfaces unless you specify that stdint.h has to
be included before them... and I'd awise against any needless interface
fattening. Besides, using them in the kernel would then mean pulling in
stdint.h there... and you get the same mess, the other way around ("What
userspace headers are OK to pull in when compiling the kernel?"). Better
don't.

[...]

> > 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. 

> If this is as unpredictable as you describe it, it would mean that also
> new interfaces which need to specify an exact integer size would require
> new sets of type names.

That's what all the _u8 and such are. Note that any name starting with _ or
__ is explicitly reserved by the standard (i.e., users should never use
them), so they are (relatively) safe.

>                         So horrors like my_uint32_t, project-specific and
> of course conflicting definitions of ULONG (really really meaning 32 bit,
> at least sometimes), etc. would still be with us for a long time.

Better use stdint.h where possible.

> Let me add that I've happily used the standard integer names for
> a while, inside and outside of the kernel, so far without ill
> effects. Maybe I've just been lucky.

No. You just haven't commited horrors like the ones Linus showed. No
halfway sane C programmer would, but they are quite legal (and must work).

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

> Okay, for me it's usually exactly the opposite :-) New tools
> that need to share fairly private interfaces with the kernel.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513