On Jan 19, 6:48am, paul%whooppee.com@localhost (Paul Goyette) wrote:
-- Subject: Re: Fixed modular kernel path and different kernels
|
| Well, yes, that's what I said above regarding modules "pushed from the
| boot loader." :-)
|
| It seems to me that we have a similar restriction on where the boot
| loader locates the /boot.cfg file. It currently comes from boot
| device, regardless of what device will eventually become your root
| device. (Indeed, if I am not mistaken, the /boot.cfg file is located
| on the _initial_ boot device that was selected by the BIOS, and not
| the device specified in any 'boot xxx' command.)
|
| Prompting for a module location at boot-loader time means you need to
| specify the path using BIOS devices (hd0, hd1, etc.), and then after
| autoconfigure is done you need to translate BIOS specification into a
| real path, which may or may not be possible (BIOS device might not be
| mounted yet, and might not even be listed in /etc/fstab).
|
|
| So, consider the following scenario:
|
| 1. boot from BIOS device cd0 with 'boot -a'
| 2. when asked, tell it to load modules from hd1a:/my_modules/ since
| that is where your test modules lie
| 3. the cd9660 file system module is pushed from file
| hd1a:/my_modules/cd9660/cd9660.kmod
| 4. the kernel continues with autoconfig()
| 5. now it prompts for a root device, and you answer "wd0"
|
| I assume that you would want subsequent module loads to come from the
| test modules on wd1a:/my_modules/ Unfortunately, we don't know where
| (or even if) wd1a will be mounted, so we cannnot translate the "hd1a:"
| device specification to a file system path. Even if we did know where
| "wda1" would be mounted, we might attempt to load modules before the
| mount occurs.
|
| As I see it, we can either
|
| a) Implement the proposed patch which tells the kernel where to find
| module which are loaded after the kernel is running, and accept
| the restriction that any modules "pushed" from the boot loader come
| from the default location, in /stand/$ARCH/$VERSION/modules/
|
| or
|
| b) Provide a prompt, within the boot-loader itself, on where to find
| modules being "pushed", in addition to the prompt I proposed which
| tells the kernel where to find modules loaded after the kernel is
| running
|
| or
|
| c) Leave things as they are, and not provide any option to specify
| the module path during boot. (Note also that the sysctl variable
| kern.module.path is Read-Only, so you cannot even change the
| location manually; changing the sysctl variable to Read-Write
| could be a security concern...)
|
|
| My preference is (a), as it addresses _most_ situations.
|
|
| FWIW, the restriction also applies to MD disk images (such as the
| miniroot module); these are pushed as modules...
I just think it is enough to override one component in the path via
a boot command; like VERSION=x.y.z.new and then both the boot loader
and the kernel can just do what they normally do. It is less general,
but gives enough flexibility for testing.