bug#48266: support dynamic loading of modules from initrd

[Ludovic Courtès]

Hi!

Vagrant Cascadian <vagrant@debian.org> skribis:

> Initially, I tried adding just the obviously mmc related modules, but
> this gave me guile prompt from the initramfs as it failed to find the
> rootfs. Notably, even with the above list, I still need to explore
> additional modules to load in order to get the display and keyboard to
> work from the initramfs, in case I wanted to use this with encrypted
> rootfs...
>
> The above list of modules could almost certainly be trimmed, but even
> getting a bootable system for pinebook pro took about 20 tries, and the
> process of defining the modules is further complicated by several
> factors...
>
> * The filesystem names of the modules (e.g. dw_mmc-pltfm) do not
>   necessarily match the runtime name from lsmod (e.g. dw_mmc_pltfm).
>   This becomes a good deal of trial and error to figure out which
>   modules to add.
>
> * One needs to manually resolve the soft and hard dependencies of the
>   modules, and ensure they are loaded, and include them in the list.
>
> * If upstream changes the module name (which does happen from time to
>   time), you have to update the system config.scm to the new module
>   names.
>
> * If some functionality changes from a module to a built-in, or
>   vice-versa, the system config.scm needs manual updating.
>
> * Switching system between two different arm boards potentially requires
>   entirely different lists of modules.

Note that ‘guix system init’, ‘reconfigure’, and ‘deploy’ error out if
drivers for a storage device are missing (see
‘check-device-initrd-modules’).

Now, that doesn’t help if you’re using ‘guix system image’, which
perhaps is what you were doing?  I wonder how we could take advantage of
that code in such a scenario.

> Rather than handling modules one at a time, I would propose to at least
> add an option that can add whole directory trees of modules to the
> initrd (e.g.  kernel/drivers/usb/)... and then use modprobe (or udev?)
> to handle the dependencies. Maybe opt-in at first, but longer-term,
> explore making it default?

I remember Danny and I worked on something along these lines in the past
but it didn’t completely materialize (some of the machinery is already
here, though).  That said, we still wouldn’t want to include too much in
the initrd, would we?

Thanks,
Ludo’.