lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH 0/2] KABI example conversion and cleanup
    Date
    On Sunday 26 March 2006 9:31 am, Eric Piel wrote:
    > I completely agree with rules 1, 2 and 5. However, IMHO rule 4 should
    > just be the inverse of rule 5: The stuff in include/linux should always
    > be independent from KABI (and userspace of course). Simply because the
    > way we _implement_ things in the kernel has to be different from the
    > things that we _specify_ in the kernel ABI.

    You know all the stuff that's marked __user? It's all kernel ABI. Having it
    defined in two places invites version skew, and the kernel needs it too
    because the kernel is parsing the stuff sent in by userspace and filling it
    out to send back to userspace.

    Lots of syscalls and ioctls and such pass a structure back and forth from
    userspace to the kernel and back, right? Doing a stat() fills out a
    structure, doing an losetup fills out a structure, and so on.

    Userspace needs to know what's in this structure. It may be wrapped in a libc
    function that fills out a different structure from the kernel structure, but
    the data that goes back and forth between the program and the kernel has to
    be defined in a header somewhere so the libc knows what the kernel's sending
    and the kernel knows what the libc is sending. (And for those functions with
    no libc wrapper, the user program needs to know the structure directly,
    somehow.)

    Having a data-marshalling ABI structure defined in two places invites version
    skew. Userspace needs access to this (at least to build a libc), and the
    kernel needs access to this, because it's a _communication_mechanism_. You
    can't have a communication mechanism that's only defined at one end.

    > As for rule 3, if you have independent headers, this should be much less
    > necessary. Additionally, keeping all the names identical to what they
    > are already called will allow userspace to just use include/kabi/ as the
    > /usr/include/linux/ directory. Avoiding smelly things like:
    >
    > linux/foo.h:
    > #define __kabi_foo foo
    > #include <kabi/foo.h>

    The #define is, indeed, smelly.

    Rob
    --
    Never bet against the cheap plastic solution.
    -
    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 23:11    [W:0.021 / U:0.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site