[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48266: support dynamic loading of modules from initrd
From: |
Vagrant Cascadian |
Subject: |
bug#48266: support dynamic loading of modules from initrd |
Date: |
Tue, 11 May 2021 15:35:07 -0700 |
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
signature.asc
Description: PGP signature