tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fixed modular kernel path and different kernels



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.

christos


Home | Main Index | Thread Index | Old Index