Messages in this thread | | | Date | Sat, 6 Nov 1999 06:56:07 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: toplevel Makefile bug and simple fix |
| |
From: Peter Samuelson <peter@wire.cadcamlab.org> 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 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/
| |