[lkml]   [2000]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

    > From: Werner Almesberger []
    > I think there are three possible directions wrt visibility of kernel
    > headers:
    > - non at all - anything that needs kernel headers needs to provide them
    > itself
    > - kernel-specific extentions only; libc is self-contained, but user
    > space can get items from .../include/linux (the current glibc
    > approach)
    > - share as much as possible; libc relies on kernel for "standard"
    > definitions (the libc5 approach, and also reasonably feasible
    > today)
    > So we get at least the following levels of visibility:
    > 0) kernel-internal interfaces; should only be visible to "base" kernel
    > 1) public kernel interfaces; should be visible to modules (exposing
    > type 0 interfaces to modules may create ways to undermine the GPL)
    > 2) interfaces to kernel-specific user space tools (modutils, mount,
    > etc.); should be visible to user space that really wants them
    > 3) interface to common non-POSIX extensions (BSD system calls, etc.);
    > should be visible to user space on request, or on an opt-out basis
    > 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be
    > visible unconditionally (**)
    The problem came in a case where I had a kernel module that included
    standard memory allocation <linux/malloc.h>. That file, in turn, included
    <linux/slab.h>, then that included <linux/mm.h> and <linux/cache.h>. From
    there more and more files were included until it got down to files in
    a kernel/kernel-module only directory "<include/kernel>". It was at that
    point, the externally compiled module "barfed", because like many modules,
    it expected, like many externally compiled modules, that it could simply
    access all of it's needed files through /usr/include/linux which it gets
    by putting /usr/include in it's path. I've seen commercial modules like
    vmware's kernel modules use a similar system where they expect
    /usr/include/linux to contain or point to headers for the currently running

    So I'm doing my compile in a 'chrooted' environment where the headers
    for the new kernel are installed. However, now, with the new include/kernel
    dir in the linux kernel, modules compiled separately out of the kernel
    tree have no way of finding hidden kernel include files -- even though
    those files may be needed for modules. Precisely -- in this case, "memory
    allocation" for the kernel (not userland) was needed. Arguably, this
    in a kernel-only directory. If that directory is not /usr/include/linux or
    *under* /usr/include/linux, then modules need a separate way to find it --
    namely a new link in /usr/include(<kernel>) to point to the new location,
    or we move the internal kernel interfaces to something under the current
    <include/linux> so while the intent of "kernel-only" is made clear, they
    are still accessible in the way they already are, thus not requiring
    of all the existing makefiles.

    I think in my specific case, perhaps, linux/malloc.h *is* a public
    interface that is to be included by module writers and belongs in the
    'public interface dir -- and that's great. But it includes files like
    'slab.h' which are kernel mm-specific that may change in the future. Those
    files should be in the private interface dir. But that dir may still need
    to be included by public interface (malloc) file.

    So the user should/needs to be blind to how that is handled. They
    shouldn't have to change their makefiles or add new links just because
    how 'malloc' implements its functionality changes. This would impy that
    kernel only interfaces need to be include-able within the current
    model -- just moved out of the existing "public-for-module" interface
    directory (/usr/include/linux). For that to happen transparently, that
    directory needs to exist under the current hierarchy (under
    not parallel.

    So at that point it becomes what we should name it under
    /usr/include/linux. Should it be:

    1) "/usr/include/linux/sys" (my preference)
    2) "/usr/include/linux/kernel"
    3) "/usr/include/linux/private"
    4) "/usr/include/linux/kernel-only"
    5) <other>


    Any other solution, as I see it, would break existing module code.

    Comments?? Any preferences from /dev/linus?

    Any flaws in my logic chain?


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

     \ /
      Last update: 2005-03-22 12:52    [W:0.034 / U:11.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site