Re: Fixed modular kernel path and different kernels

[Paul Goyette <paul%whooppee.com@localhost>]

On Wed, 18 Jan 2017, Christos Zoulas wrote:

> In article <Pine.NEB.4.64.1701181346340.24490%speedy.whooppee.com@localhost>,
> Paul Goyette  <paul%whooppee.com@localhost> wrote:
> > -=-=-=-=-=-
> >
> > On Wed, 18 Jan 2017, Paul Goyette wrote:
> >
> > > > One obvious and trivial way to allow for testing like this is to have
> > > > boot -a also ask for an override of the module path.
> > >
> > > This should not be too difficult, although it would (continue to) have
> > > the restriction that modules "pushed" from the boot loader (those
> > > which are loaded via /boot.conf as well as those automatically pushed
> > > for non-ffs boot-device file systems) would continue to be loaded from
> > > the boot device.
> > >
> > > > Once that is there, also provide the override via userconf or
> > > > /boot.cfg.
> > >
> > > Would this really be necessary?  Do we have the ability to set the
> > > root file system via userconf or /boot.cfg?  (Neither the boot.cfg(5)
> > > nor userconf(4) man pages hint that this is available?)
> > >
> > >
> > > With a goal of improving the useability of kernel modularity, I'd be
> > > happy to implement this capability (WRT boot -a), if there's some sort
> > > of consensus.
> >
> > I've gone ahead and implemented this - see attached patches.
> >
> > Code review appreciated, as well as comments on whether or not this
> > should be committed.
>
> I think this should happen at boot loader time, otherwise it is too
> [late] for preloaded modules?

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...




+------------------+--------------------------+------------------------+
| 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 |
+------------------+--------------------------+------------------------+