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



OK, I looked into this a bit more.

Doing the 'prompt for module path' thing is non-trivial, at least for someone who is totally unfamiliar with the boot code, and I'm not willing to dedicate that much effort to the required learning curve.

I'm happy to commit the changes I already posted, but only if there is some sort of indication that the changes would be welcomed. Otherwise I'll do nothing.



On Thu, 19 Jan 2017, Paul Goyette wrote:

On Wed, 18 Jan 2017, Christos Zoulas wrote:

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.

Hmmm.  That's probably reasonable.

But if we're going to do it in the boot loader, shouldn't we just add
a new command?  Waiting until the 'boot -a' command is entered (either
directly or via a menu selection) seems wrong.

We already have

	modules [ off | on | enabled | disabled ]

We could add

	modules version=[dir]


Would this be acceptable?



+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+

!DSPAM:5880017c70821312614758!



+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+


Home | Main Index | Thread Index | Old Index