lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure
    Date
    On Mar 26, 2006, at 07:32:31, Arjan van de Ven wrote:
    > On Sun, 2006-03-26 at 06:54 -0500, Kyle Moffett wrote:
    >> Create initial kernel ABI header infrastructure
    >
    > it's nice that you picked this one;
    > for this you want an arch-generic/stddef32.h and stddef64.h
    >
    > and have arch-foo just only include the proper generic one..

    I plan to add a lot of other definitions to this file later on. For
    example different architectures have different notions of what a
    __kernel_ino_t is (unsigned int versus unsigned long). I may rename
    this file as types.h, but from looking through the code I figure I'll
    have enough general purpose declarations about "This architecture has
    blah" that a separate stddef.h file will be worth it.

    > (and... why do you prefix these with _KABI? that's a mistake imo.
    > Don't bother with that. Really. Either these need exporting to
    > userspace, but then either use __ as prefix or don't use a prefix.
    > But KABI.. No.)

    According to the various standards all symbols beginning with __ are
    reserved for "The Implementation", including the compiler, the
    standard library, the kernel, etc. In order to avoid clashing with
    any/all of those, I picked the __KABI_ and __kabi_ prefixes for
    uniqueness. In theory I could just use __, but there are problems
    with that too. For example, note how the current compiler.h files
    redefine __always_inline to mean something kinda different. The GCC
    manual says we should be able to write this:

    inline __attribute__((__always_inline)) int increment(int x)
    {
    return x+1;
    }

    Except when compiling the kernel headers turn that into this (which
    obviously doesn't compile):
    inline __attribute__((__attribute__((always_inline)))) int increment
    (int x)
    {
    return x+1;
    }

    As a result, I kinda want to stay away from anything that remotely
    looks like a conflicting namespace. Using such a unique namespace
    means we can also safely do this if necessary (Since you can't
    "typedef struct foo struct bar"):

    kabi/foo.h:
    struct __kabi_foo {
    int x;
    int y;
    };

    linux/foo.h:
    #define __kabi_foo foo
    #include <kabi/foo.h>

    drivers/foo/foo.h:
    #include <linux/foo.h>
    void func()
    {
    struct foo = { .x = 1, .y = 2 };
    }

    Cheers,
    Kyle Moffett

    -
    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: 2006-03-26 14:53    [W:0.032 / U:186.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site