From: torvalds@transmeta.com (Linus Torvalds)
Date: 27 Jul 2000 00:39:51 -0700
I would suggest that people who compile new kernels should:
- NOT do so in /usr/src. Leave whatever kernel (probably only the
header files) that the distribution came with there, but don't touch
it.
- compile the kernel in their own home directory, as their very own
selves. No need to be root to compile the kernel. You need to be root
to _install_ the kernel, but that's different.
- not have a single symbolic link in sight (except the one that the
kernel build itself sets up, namely the "linux/include/asm" symlink
that is only used for the internal kernel compile itself)
May I suggest one slight change to this list? /usr/src/linux should be
a symlink to the header files of whatever kernel is being booted by
default. So you can compile your own kernel in your own home directory,
but when you install your own kernel as the default boot kernel,
/usr/src/linux should point to the header files of that kernel. As you
say, it requres root to _install_ your own kernel, and that point, you
can point /usr/src/linux at the appropriate place.
This allows source packages which generate kernel modules which have to
link against the current kernel ---- such as the external pcmcia driver,
hich you've recommended that distro's use since 2.4's pcmcia support
isn't quite up to snuff yet ---- be able to reliably find (or at least
present the user with a sensible default) the header files of the kernel
which is being installed as the default boot kernel.
And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.
The problem is that unless you are trying to say that you want to outlaw
external source packages which generate kernel modules, there needs to
be some way for such packages to be able to find the kernel header
files.
Other solutions include having a standard mechanism for dropping
external packages into the kernel source tree, which will then compile
those modules as their own. (Apache supports a model like this).
Or, we could make some other symlink point at the sources of the kernel
which is booting by default.
The fact that people need to solve this problem is one of the reasons I
think the old model has lived on for so long.
The other problem which comes up is that they need to compile some new
kernel utility program, which by virtue of the fact that it's using some
new ioctl, needs access to the latest kernel header files. These
programs are the exception, though, not the rule, and one can argue that
in this case they can simply carry their own header files with them.
(That's incredibly clumsy, though, and means that a lot of header files
will have to get duplicated; and as one person has pointed out, in some
cases, may mean that you have to bring several copies of the the asm-*
header files since some ioctl structures are architecture dependent.)
Alternatively, I suppose you could say that all such kernel utility
programs have to be packaged with the kernel; but do we really want to
be making the kernel that much bigger? :-)
- Ted
-
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 : Mon Jul 31 2000 - 21:00:23 EST