[lkml]   [2004]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__

    On Tue, 14 Dec 2004, Werner Almesberger wrote:
    > Hmm, so you're predicting problems if user space includes something
    > that uses uint32_t ? Wouldn't either of these work (descriptive file
    > names for clarity):
    > 1) include/linux-user/foo.h:
    > #include <stdint.h>
    > #include <linux-kernel-and-user-common/foo.h>

    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.

    The user is supposed to see "int32_t" and friends _only_ if the user
    himself includes <stdint.h> or one of the very specific headers that is
    documented by the standard to include it.

    Trust me. We are NOT going to use <stdint.h> in the kernel.

    This is a common issue with namespace pollution. For example, this program
    is perfectly valid afaik (well, except for being _stupid_, but that's
    another issue):

    #include <stdio.h>

    const char *int32_t(int i)
    return i ? "non-zero" : "zero";

    int main(int argc, char **argv)
    return printf("argc is %s\n", int32_t(argc));

    Get the picture? The user may _use_ names that are defined for the
    standard - like "strlen()" or "uint32_t" - for his own nefarious purposes,
    because they are _only_ defined if you include the right header files.

    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.

    And that is why a kernel header file must not define them, and by
    implication, cannot use these names.

    Because the whole _point_ of having kernel header files that can be used
    in user-space is that they are helpers for things like <sys/ioctl.h> etc,
    that would just copy them.

    If we are going to pollute the user-visible namespace in random ways, the
    whole discussion is pointless. At that point, glibc (or any other libc)
    can't use those API headers anyway.

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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.020 / U:0.136 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site