lkml.org 
[lkml]   [2004]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
    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/____________________________________________/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:6.667 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site