Messages in this thread | | | Date | Thu, 27 Jul 2000 10:31:10 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: RLIM_INFINITY inconsistency between archs |
| |
"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/
| |