bug#48266: support dynamic loading of modules from initrd

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

On 2021-05-11, Ludovic Courtès wrote:
> 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’).

Yes, I often have to tell it to skip those checks when using 'guix
system init', as I'm installing to a microSD card by way of a
usb-to-microSD adapter, and it guesses all the wrong 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.

I sometimes do 'guix system image' for the initial pass, and then
follow-up with init or reconfigure...


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

Notably, at the moment it loads various virtio modules on all my
baremetal systems, which is a bit uneccesary. :)

Honestly, when debugging support for a new arm system, I'm of the
opinion that more is better than less, as it takes way too many
iterations to get to a working modular configuration. So at least an
option to include even the kitchen sink drivers would be nice. :)


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]