> 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
drivers.)
- 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/