Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 11/29/04

  • Next message: Adrian Bunk: "[2.6 patch] drivers/w1/: possible cleanups" 
    Date:	Sun, 28 Nov 2004 17:28:53 -0800 (PST)
To: Paul Mackerras <paulus@samba.org>

    On Mon, 29 Nov 2004, Paul Mackerras wrote:
    >
    > uint32_t is defined to be exactly 32 bits wide, so where's the problem
    > in using it instead of __u32 in the headers that describe the
    > user/kernel interface? (Ditto for uint{8,16,64}_t, of course.

    Ok, this discussion has gone on for too long anyway, but let's make it
    easier for everybody. The kernel uses u8/u16/u32 because:

            - the kernel should not depend on, or pollute user-space naming.
              YOU MUST NOT USE "uint32_t" when that may not be defined, and
              user-space rules for when it is defined are arcane and totally
              arbitrary.

            - since the kernel cannot use those types for anything that is
              visible to user space anyway, there has to be alternate names.
              The tradition is to prepend two underscores, so the kernel would
              have to use "__uint32_t" etc for its header files.

            - at that point, there's no longer any valid argument that it's a
              "standard type" (it ain't), and I personally find it a lot more
              readable to just use the types that the kernel has always used:
              __u8/__u16/__u32. For stuff that is only used for the kernel,
              the shorter "u8/u16/u32" versions may be used.

    In short: having the kernel use the same names as user space is ACTIVELY
    BAD, exactly because those names have standards-defined visibility, which
    means that the kernel _cannot_ use them in all places anyway. So don't
    even _try_.

    On the bigger question of what to do with kernel headers in general, let's
    just make one thing clear: the kernel headers are for the kernel, and big
    and painful re-organizations that don't help _existing_ user space are not
    going to happen.

    In particular, any re-organization that breaks _existing_ uses is totally
    pointless. If you break existing uses, you might as well _not_ re-
    organize, since if you consider kernel headers to be purely kernel-
    internal (like they should be, but hey, reality trumps any wishes we might
    have), then the current organization is perfectly fine.

    So I think this whole discussion has been largely pointless. We undeniably
    have existing users of kernel headers. That's just a fact. If we break
    them, it doesn't _matter_ how the kernel headers look, and then "existing
    practice" is about as good an organization as anything, and breaking
    things just to break things is not something I'm in the least interested
    in. "Beauty" comes secondary to "usefulness".

    So I would encourage people to think about ways to clean up some of the
    worst warts, but take into account:
     - testing it out with whatever random collection of old distributions and
       special applications is almost impossible. So every single step of the
       way should be (a) small and (b) obviously not break any current users.
     - cleanup just for the sake of cleanup always needs to take pain into
       account. If you cannot make each small step "worth it", then just don't
       do it. If the "cleanup" just adds another file and doesn't actually
       _help_ anything that you can point to, it's not a cleanup, it's just an
       exercise in wanking.

    IOW, I seriously doubt any "let's reorganize header files just to make it
    look good" _ever_ accomplished anything. But if there are _specific_
    header files that have _specific_ problems, let's look at maybe solving
    those. And if you cannot point to a specific problem with a suggested
    specific solution, please don't cc me.

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

  • Next message: Adrian Bunk: "[2.6 patch] drivers/w1/: possible cleanups"

    Relevant Pages

    • RE: Illegal use of reserved word in system.h
      ... The correct word is invalid, ... There should not be any "illegal" strings in the kernel either although they sometimes creep in... ... There is no other operating system except BSD that gives user mode code access to kernel-headers. ... people have been able to write working code using those operating systems without using kernel headers. ...
      (Linux-Kernel)
    • Re: [PATCH] Re: [PATCH] scsi.h uses "u8" which isnt defined.
      ... > Kernel developers have been telling people for years, ... As a kernel developer I regularly tell people to make their ... own private copy of the bits of kernel headers they need, ... user space, since that is the one and only spot that contains all ...
      (Linux-Kernel)
    • Re: State of userland headers
      ... original kernel headers for anything, and only later, after achieving ... llh for the most popular archs and figure out how to build all the various ... Not like the old llh (x.y.z.t, ... greater than 8 bits or DMA for cd burning, we need new kernel headers. ...
      (Linux-Kernel)
    • Adding Developmetn Tools - Fedora 3
      ... The kernel is Fedora3 ... and noticed that the compiler was missing. ... kernel headers I could not add them in. ... Tools as I would normally do in a standard Fedora 3 install. ...
      (RedHat)
    • RE: Illegal use of reserved word in system.h
      ... grep of `strings vmlinux`.... ... IllegalLengthIndication ... The kernel headers are clean. ...
      (Linux-Kernel)