Digby Tarvin schreef: > On Wed, Nov 09, 2005 at 03:35:42PM +0100, Holly Bostick wrote: > >> -- If you have some external module that compiles against the >> kernel source, you most likely need it against *all* kernel >> sources, not just the running one (so redirecting the link is only >> of limited usefulness); > > > Ok - this seems to be the bit that I am a little unclear on. > > If there are, as indicated in your earlier response (which I was > still mulling over) "applications, libraries and external kernel > modules" that need to be compiled against a kernel,
Not against a kernel. Against a kernel *source*. These are not the same thing. The kernel you actually boot is a binary file, compiled from the source in /usr/src/whatever. When it is compiled, you copy the binary to /boot, and that is what you boot. That is the meaning of 'make install'. Like any binary, once compiled it is 'detatched', let us say, from the source, and is no longer related to it in that any changes to the source do not affect the compiled binary-- if you make a change to the source, you have to recompile the binary to reflect the changes in the new binary. > and we want to be able to use grubs ability to select from a choice > of kernels, what is the mechanism by these we ensure the correct > applications, libraries and external kernel modules (lets call them > 'objects' to avoid having to list the possibilities each time - not > to be confused with the current trendy programming paradigm) are used > for the currently running kernel? If you compiled the objects against the source of the kernel under consideration -- and this is the purpose of the /usr/src/linux symlink, to tell the emerge which kernel source the objects should be compiled against, then they are compiled against the source of the kernel .... Let me put it this way. ati-drivers (the proprietary drivers for ATI video cards) are an external kernel module. External, because they are not contained in the kernel source (being proprietary), but a kernel module because they 'hook' into the kernel as a normal module. When I compile them, here is the beginning of the output: Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: 2.6.13-gentoo-r4 Checking for MTRR support enabled ... Checking for AGP support enabled ... Checking for DRM support disabled ... X11 implementation is xorg-x11. |>>> Unpacking source... Unpacking Ati drivers ... The drivers, like all other drivers, need certain kernel functions to be available (or not available) in order to operate correctly; so because this driver must compile against the kernel source, the script checks to confirm that the necessary kernel functions are enabled/disabled prior to compiling.This is why you must compile against a *configured* kernel source (it need not be compiled, but it must be configured, so that the script can determine what functions will be available in the kernel binary). As you see, this emerge of the ATI drivers compiled against the source of 2.6.13-gentoo-r4, because that was where the /usr/src/symlink was pointing when I performed the emerge. This was in fact an upgrade to the driver, and 2.6.13-r4 was my currently-running kernel. However, later, I downloaded and configured 2.6.14, and re-emerged the ATI drivers (I use the "symlink" USE flag, so the symlink was automatically redirected): Determining the location of the kernel source code Found kernel source directory: /usr/src/linux Found sources for kernel version: 2.6.14-gentoo Checking for MTRR support enabled ... Checking for AGP support enabled ... Checking for DRM support disabled ... X11 implementation is xorg-x11. |>>> Unpacking source... This emerge compiled against the source of 2.6.14-gentoo, because the /usr/src/linux symlink was redirected to the source of that kernel. Both kernels now have the ATI drivers compiled for them, because when compiled (either during a kernel compile, or an external module compile), modules are placed in a kernel-specific directory: la /lib/modules totaal 9 drwxr-xr-x 12 root root 384 nov 7 15:43 . drwxr-xr-x 12 root root 5688 nov 7 16:34 .. drwxr-xr-x 5 root root 472 mei 25 17:29 2.6.11-ck8-r1 drwxr-xr-x 4 root root 448 jul 24 00:04 2.6.11-gentoo-r11 drwxr-xr-x 5 root root 472 jun 15 03:06 2.6.11-gentoo-r6 drwxr-xr-x 5 root root 472 jul 7 02:17 2.6.11-gentoo-r8 drwxr-xr-x 6 root root 496 okt 13 14:53 2.6.12-gentoo-r10 drwxr-xr-x 4 root root 448 aug 19 06:36 2.6.12-gentoo-r6 drwxr-xr-x 4 root root 448 sep 2 05:39 2.6.12-gentoo-r9 drwxr-xr-x 6 root root 496 nov 7 18:30 2.6.13-gentoo-r4 drwxr-xr-x 6 root root 496 nov 7 19:03 2.6.14-gentoo and within it: la /lib/modules/2.6.13-gentoo-r4/video totaal 317 drwxr-xr-x 2 root root 72 nov 7 18:00 . drwxr-xr-x 6 root root 496 nov 7 18:30 .. -rw-r--r-- 1 root root 321951 nov 7 18:00 fglrx.ko la /lib/modules/2.6.14-gentoo/video totaal 317 drwxr-xr-x 2 root root 72 nov 7 18:14 . drwxr-xr-x 6 root root 496 nov 7 19:03 .. -rw-r--r-- 1 root root 321951 nov 7 18:14 fglrx.ko So no matter which kernel I'm booting, when that kernel calls the 'fglrx' module, the kernel will retrieve the appropriate module from its own /lib/modules folder. The kernel source in /usr/src, is no longer needed. You could in fact delete it, without hurting anything, unless you needed to recompile something against it, which you probably don't, especially if it's two or more kernels back. In fact, having done that ls -la I see I still have available modules for kernels I don't have any more (deleted from source and deleted from /boot). So I might as well get rid of those /lib/modules folders, too. > > If the binaries are to be stored in a kernel dependent location, like > the kernel modules build within the kernel source tree that are > built to /lib/modules/<kernel-version>, then /usr/src/linux cannot > really be being used as a symlink (ie a way of accessing the kernel > files without needing to know which version it is) because the build > process will need to know the target kernel version in order to make > the directory names or tag. In effect, it could equally well be a > file called '/usr/src/build-kernel' which contains the version number > of the kernel being compiled for...? Probably, and lots of people feel that the symlink is stupid (iirc, Linus is one of them). But it's an organizational thing that's been done for a loooong time, and there is a case for it being of some usefulness. And certainly nobody (or very few distros) want to go all independent and rename things madly, when everybody at least understands and has some sense of security that /usr/src/linux points to a kernel source, most likely the currently-running one, or, for a short time, the configured-but-about-to-be-compiled kernel, that *will* be the currently running kernel as soon as you compile, install and reboot to it. > > Anyway, if I understand you correctly, if you are not building > anything, then it doesn't matter. Not if you're not building anything against the kernel source, no. > And there is certainly no justification is assuming you are building > for the kernel that is currently running. Right? No, there is not-- and if you are a special case like Glenn, then you know what you're doing anyway. His situation should certainly not be taken as the norm. > > Presumably these kernel dependent objects only need emerge to > download the source once, but then must be rebuilt once for each > kernel you want to install - right? And somehow the binaries will be > kept separate and the correct ones chosen at boot time based on the > active kernels knowledge of its own version identity. Yes. > > Is this what 'sys-kernel/module-rebuild' is intended to take care or > for us? So we just /usr/src/linux to the newly installed kernel and > run module-rebuild and the kernel dependent modules will all be made > for the new (or modified) kernel. Yes. > > It seems that the desirablility of having the boot process > automatically update the symlink depends on how much you want to be > able to use /usr/src/linux as a shorthand for manually typing > "/usr/src/linux-`uname -r`", which is probably a bit arcane for a > nieve user... You don't even have to do this, there is a "symlink" USE flag associated with the kernel source that will redirect the symlink when a new kernel source is downloaded. Which means that you should pay attention to what kernel sources you download, but then again, that's just normal Gentoo "paying attention", so I don't consider it a problem. > > >> Not getting it at all. How many kernels does one keep in a bootable >> state, anyway-- and use commonly, without needed external modules, >> no less-- that this would be necessary? > > > I typically have 3-4. The current which I think is fully working, the > previous kernel just in case I discover I was wrong and had > forgotten to test something vital, and the new kernel which I am in > the process of installing but havn't finished testing enough to use > when doing something important or letting others on the system.. Why you're testing an additional new kernel when you're not sure the current one fully works is confusing to me--- but it's your box. > > I also have several kernels which boot to different filesystems (eg > the old SuSE system because its crypto filesystem is not compatible > with the gentoo one) and alternate operating systems such as > BSD/Plan9/Inferno/OS-9000 - can't think of any others worth running > just now ;) > > But being different filesystems, they arn't relevent to the > /usr/src/linux link question. Being different OSes/distros, they're not relevant. Holly -- gentoo-user@gentoo.org mailing list
