"Theodore Y. Ts'o" <tytso@MIT.EDU>:
>
> 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.
>
[snip]
Might I suggest creating a "/lib/include" that works something like
the /lib/modules where the kernel name is used to generate the directory
for the kernel include files?
That way the "uname -r" command could be used to set a symbolic link
to point to the correct include files at boot time (or install time).
Since /lib/include could contain
2.4.0/(kernel includes)
2.4.0-SMP/(kernel includes)
2.4.0-RSBAC.SMP/(kernel includes)
Then at boot time (before SV init or init really takes over)
the commands:
( cd /lib/include
rm linux
ln -s `uname -r` linux )
This way the kernel that is active would be selecting the correct includes.
The build makefile could have an additional target - includes, that
would create the directory and copy the include files.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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