[lkml]   [1999]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: toplevel Makefile bug and simple fix
       From: Peter Samuelson <>
    Date: Fri, 5 Nov 1999 22:45:26 -0600 (CST)

    > Every distro I've ever played with has symlinks for
    > /usr/include/linux and /usr/include/asm into their respective
    > directories in /usr/src/linux/include.. So I've just assumed that
    > that's the right way to do it...

    Apparently you haven't played with Debian recently:

    The symlinks used to be the right way to do it. But I believe some
    time ago the glibc maintainers decided to copy the kernel headers
    rather than continue to symlink them. There are good points and bad
    points about doing this (I'm not sure I agree with Linus and the glibc
    people), but the decision has been made.

    Note, though, that it is **very** important that /usr/include/linux and
    /usr/include/asm correspond to the default kernel that you are booting.

    This is because if you are building stand-alone linux kernel modules
    from source, they need an easy way of finding the linux kernel headers
    of the kernel you are booting; otherwise, they can't get the right
    modversions.h information (for example).

    Broken distributions like Slackware used to make /usr/include/linux and
    /usr/include/asm not be symlinks, and this was a disaster, because they
    would then upgrade the kernel indepedently of /usr/include, and it meant
    that I could not support my stand-alone device drivers that are
    distributed in source form.

    Before people start flaming me, this is independent of whether
    user-programs should be referencing linux/* or asm/* header files.
    That's what was decided long ago; not that /usr/include/linux shouldn't
    be a symlink (Redhat still uses a symlink, thank God.) That's because
    kernel modules *have* to refer to these header files, and they *have* to
    correspond exactly to the kernel you wish to use them with. At the
    moment, it's best for the less-clueful users if the /usr/include/linux
    corresponds to the default kernel that will be booted, and that means a
    symlink to /usr/src/linux may be better way of doing things.

    If as a result of Debian's choice, I get too many clueless Debian users
    asking me how to make the stand-alone Comtrol Rocketport or stand-alone
    updated serial driver (with PCI support) work under Debian, I will have
    no choice but to tell them that I no longer support Debian systems, and
    to go elsewhere for support (or go to another distribution). I don't
    want to do this, but if Debian's actions mean that I spend too much time
    dealing with a support nightmare, I will have no choice.

    (This is nothing against Debian personally; I did the same for Slackware
    when Slackware users became my number one support load for those

    - Ted

    P.S. And we really *have* to be able to support stand-alone source
    distribution of drivers. The Linux kernel sources are still growing
    expenontially, with a time constant of roughly 18 months. This is
    mostly due to new drivers. Sooner or later, we will need to address the
    question of how to distribute drivers independently of the kernel, in
    source form at the very least.

    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 13:54    [W:0.028 / U:0.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site