Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Werner Almesberger <wa@almesberger.net>]

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.

Hmm, the POSIX 1003.1 2004 edition (which includes SuS) wisely
remains silent on the issue of sys/ioctl.h, but I see what you
mean.

I think some of my confusion arises from the fact that there aren't
many well-known interfaces that use uint32_t and friends to start
with. Instead, they use ssize_t, off_t and such (which admittedly
have similar problems, e.g. in cases where one can't simply get all
of sys/types.h), or private inventions like u_int32_t and such.

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.

Would you agree that the use of stdint.h types is acceptable for
new interfaces, provided that these come with the warning that
their use may pull in all of stdint.h ?

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

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.

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

Thanks,
- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/