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

    On Tue, 30 Nov 2004, David Howells wrote:
    > > But in general, I do kind of like the explicit marking. The same way we
    > > explicitly mark the functions inside the kernel that we expose to modules,
    > > we could try to mark the data structures and values that we expose to user
    > > space. That tends to "work".
    > That gets trickier when it comes to #defines, I think.
    > Do you really object that much to splitting the header files as I proposed?

    I object sternuously to your "the header files". If you can't even say
    _which_ header file, I'm not interested.

    If you can say "these X header files have this specific problem Y, and if
    we move part Z into a common area A, we'd solve it because B", that's a
    different matter.

    See what I'm saying? Whole-sale "move things around because we want to"
    I'm not interested in. Specific problems, yes.

    > Personally, I'd prefer us to move to using standard C99 types in lieu of u32
    > and co at least for the interface to userspace because they are just that:
    > standard.

    No. I told you why it cannot and MUST NOT be done. Repeat after me:


    There are many cases where including a header file means you want the
    structure, but it does _not_ mean that you can expose totally unrelated
    types, even if those types happen to be used as part of the structure. See
    what I'm saying?

    In contrast, __u8/__u16/__xxx are explicitly defined by the relevant
    standards to be "system name space", and that is _exactly_ why we don't
    use the standard namespaces.

    And the fact is, the rules for _when_ you export _which_ standard types
    are just too damn hard, and more importantly, they are not something that
    the kernel headers should even be deciding. They depend on glibc internal
    things like __USE_BSD etc, and they depend on which standard you compile
    for, and sometimes even on which _version_ of the standard you compile

    I will not have that mess in the kernel. Which means that we do _not_
    export any of the standard names. Which means that we can't _use_ any of
    them. End of story.

    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.021 / U:1.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site