support dynamic loading of modules from initrd

OpenSubmitted by Vagrant Cascadian.
Details
2 participants
  • Ludovic Courtès
  • Vagrant Cascadian
Owner
unassigned
Severity
normal
V
V
Vagrant Cascadian wrote on 6 May 22:56 +0200
(address . bug-guix@gnu.org)
87pmy3shrq.fsf@yucca
There should be an option to support dynamic loading of modules from theinitrd.
I recently pushed some changes to use the "linux-libre" kernel withpinebook pro:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d330d63a29f35ebcbebce19b13d49c69d38a5815
But in order to even boot, I need to add a lot of modules toinitrd-modules:
(initrd-modules (append (list "rtc-rk808" "dw_mmc" "dw_mmc-pltfm" "dw_mmc-rockchip" "joydev" "bluetooth" "jitterentropy_rng" "hid_generic" "videodev" "ghash_ce" "gf128mul" "ansi_cprng" "mc" "sha2_ce" "usbhid" "panfrost" "ecdh_generic" ;; "fusb302" "ofpart" ;; "tcpm" "hid" "ecc" "evdev" "leds_gpio" "io_domain" "dw_wdt" ;; "rockchip-thermal" "cw2015_battery" "pwm-rockchip" ;; "gpio_charger" "cpufreq_dt" "configfs" "xhci-plat-hcd" "xhci-hcd" "rk808-regulator" "clk-rk808" "udc-core" "ulpi" "fan53555" "rk808" "pwm-regulator" "fixed" "gpio_keys" "cec" ;; "phy-rockchip-typec" "phy-rockchip-emmc" "phy-rockchip-inno-usb2" ;; "analogix-dp" "sdhci-of-arasan" "sdhci-pltfm" "cqhci" "drm_kms_helper" "ohci-platform" "ohci-hcd" "ehci-platform" "panel-simple" "ehci-hcd" "sdhci" "drm" "i2c-rk3x" "usbcore" "pl330" "pwm_bl" "dwc3" ) %base-initrd-modules))
Initially, I tried adding just the obviously mmc related modules, butthis gave me guile prompt from the initramfs as it failed to find therootfs. Notably, even with the above list, I still need to exploreadditional modules to load in order to get the display and keyboard towork from the initramfs, in case I wanted to use this with encryptedrootfs...
The above list of modules could almost certainly be trimmed, but evengetting a bootable system for pinebook pro took about 20 tries, and theprocess of defining the modules is further complicated by severalfactors...
* 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.

Rather than handling modules one at a time, I would propose to at leastadd an option that can add whole directory trees of modules to theinitrd (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?

In Debian, adding modules to the intird is done in initramfs-tools:
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/f350f122a244c60f91a3e3e5f8b58f9cb75308b6/hook-functions#L599
As for which modules to load at runtime, initramfs-tools uses udev;maybe that could be integrated into the guix initramfs as an option?
Obviously, adding more modules than a strict bare minimum to the initrdwill increase boot times a bit, and adding further dependencies(modprobe, udev) to the initrd will add to that even more, but thecurrent hard-coded list of modules to load, that you can extend withanother hard-coded list, is a bit painful when trying to get a newsystem working...

Maybe the Guix way to do this is to write some guile code that cangenerate the list of modules to include in the initrd at build time? Butthat still doesn't resolve the dynamic loading of modules at runtime,and it would be impractical to load *all* the modules at runtime... andmaybe impractical to re-implement modprobe and/or udev in guile?

Well, thanks for considering!

live well, vagrant
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYJRYCgAKCRDcUY/If5cWqoGHAQDyNF3KxmMy43ZiU4oIK7WWhj/Qb8sAqkjqGPGSPi/IhwEAjPdH5SHFAA3puSnpUt8FgERfhAHFHii1VmuUzDbG3AM==FSHa-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 11 May 23:08 +0200
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 48266@debbugs.gnu.org)
87sg2tugfg.fsf@gnu.org
Hi!
Vagrant Cascadian <vagrant@debian.org> skribis:
Toggle quote (30 lines)> 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 ifdrivers for a storage device are missing (see‘check-device-initrd-modules’).
Now, that doesn’t help if you’re using ‘guix system image’, whichperhaps is what you were doing? I wonder how we could take advantage ofthat code in such a scenario.
Toggle quote (6 lines)> 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 pastbut it didn’t completely materialize (some of the machinery is alreadyhere, though). That said, we still wouldn’t want to include too much inthe initrd, would we?
Thanks,Ludo’.
V
V
Vagrant Cascadian wrote on 12 May 00:35 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48266@debbugs.gnu.org)
87lf8krjac.fsf@yucca
On 2021-05-11, Ludovic Courtès wrote:
Toggle quote (36 lines)> 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 'guixsystem init', as I'm installing to a microSD card by way of ausb-to-microSD adapter, and it guesses all the wrong modules.

Toggle quote (4 lines)> 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 thenfollow-up with init or reconfigure...

Toggle quote (11 lines)>> 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 mybaremetal systems, which is a bit uneccesary. :)
Honestly, when debugging support for a new arm system, I'm of theopinion that more is better than less, as it takes way too manyiterations to get to a working modular configuration. So at least anoption to include even the kitchen sink drivers would be nice. :)

live well, vagrant
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYJsGmwAKCRDcUY/If5cWqsxNAP9tuIdRlpCHQID0+HpLkNiT5mU5WSvQcXgdZykNU3rdxgD+Ko9ZmpXOh4qrLICpdD1eaO0tT6uGcfyBkplYf0urrQE==CFt4-----END PGP SIGNATURE-----
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 48266@debbugs.gnu.org