> 1) You need headers in /usr/include/linux. For 2.3.x/2.4.x kernels it
> is generally assumed that the systemwide /usr/include/linux should be
> upgraded independently of the kernel includes.
>
> .... except if you want to build stand-alone kernel modules that work
> against the kernel that you are currently booting.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It is dangerous to even assume you can figure that one out reliably.
For compiling external modules you _have_ to specify the exact kernel
location or it won't work. Not in the general case, where you have to
expect four different kernel versions configured for three different
machines somewhere in the filesystem and the "wrong" one linked into
/usr/include.
> This still requires that /usr/include/linux and /usr/include/asm match
> the kernel you are currently building. Some packages will now use
> /usr/src/linux/include/{linux,asm} in preference if they exist, or allow
> the user to manually specify the location of the kernel source tree to
> use, but these conventions haven't been universally standardized yet.
They have to be strictly standardized, or people will break them. Look
at the insanity Red Hat put into <linux/version.h>. :-(
It would be better if /usr/include/{linux,asm} could be removed
altogether, so people could see something is missing if it is missing.
> Doing so would be a good idea, BTW. If we can all agree that "this is
> the way to do things in Linux 2.4", and make sure all of the
> distributions are informed of that fact, that would be Good Thing (tm).
And make sure that Red Hat et al. stop distributing kernels which
horribly break if you do the perfectly normal task of compiling more
than one kernel on any one machine.
> My personal nomination of the standard way to do things is to assume
> that /usr/src/linux is a symlink to kernel sources corresponding to the
> default kernel being booted on that machine, and that stand-alone device
> drivers that need to compile against a kernel should default to
> /usr/src/linux, but there should be an easy way for users to override
> that and specify some other kernel source tree if necessary. Any
> objections to such an approach?
This is what I'm doing for years now, and it works (despite frequent
attacks of glibc or debian upgrades on the integrity of the include tree).
Olaf
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:09 EST