[lkml]   [2005]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC] Splitting out kernel<=>userspace ABI headers
    A while ago there was a big discussion about splitting out the
    userspace-accessible portions of the kernel headers into a separate
    directory, "kabi", "kernel-abi", "linux-abi", or a half-dozen other
    suggestions. Linus sprinkled a bit of holy-penguin-pee on the idea,
    but nothing ever really happened after that. I have some available
    time at the moment, and I would be willing to undertake the task,
    but I would like a bit of guidance first, both from Linus/akpm/etc,
    and from the list in general, about a few initial issues I see from
    my initial attempts to sort through the mess:

    1) There are a couple header files upon which almost everything
    else depends, among them {asm,linux}/{posix_,}types.h, which have
    some significant duplications. Many of the archs have weird sizes
    for those types to preserve some backwards-compatibility ABI, but
    nowhere does it explain if there are any type-size restrictions in
    general. I would propose that those headers be reorganized so that
    there are sane defaults for all the types in kabi/types.h, and
    archs that require different would #define exceptions in their
    kabi/arch-foo/types.h. This would allow new archs to start with a
    sane standard ABI before it becomes set in stone.

    2) There is a bunch of stuff that would be _really_ useful in
    userspace programs as well, even though not kernel ABI, such as
    list.h, atomic.h (with a few archs modified due to privilege
    restrictions), etc. If there is interest, I would attempt to split
    off those headers into a kcore/kerncore/linuxcore/whatever inline
    header collection included in the linux distribution and installed
    as part of the kernel headers.

    3) What names are preferable for the above? My personal
    preferences are "kabi" and "kcore", because those save the most
    typing for the sucker trying to do all this (IE: me), although if
    someone has good reasons otherwise, I'll listen.

    I realize this project is only slightly short of massive, however I
    do have a bunch of time and am willing to do the grunt work if
    enlightened as to the community desires. I have a few different
    semi-patches almost ready, and I can probably finish up a couple
    this weekend if I can figure out which way people want to go. One
    of the major challenges is that kernel files have historically kind
    of indiscriminately included asm/foo.h when they really meant
    linux/foo.h (See the types.h example), only to have it magically
    work because some other header already included linux/types.h
    anyways. If arch/driver/etc maintainers are willing to take patches
    to clean that up, I'll start with that and eventually get a decent
    set of kabi/* headers.

    Kyle Moffett

    Unix was not designed to stop people from doing stupid things,
    because that
    would also stop them from doing clever things.
    -- Doug Gwyn

    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: 2005-09-02 05:02    [W:0.021 / U:0.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site