Hi, On Tue, 09 Jul 2019 00:50:10 +0200 Jelle Licht <jli...@fsfe.org> wrote:
> I have verified this way of loading modules to work, but was wondering > whether we should rather provide a `out-of-tree-kernel-module' service > of sorts to do this. > > To resolve out-of-tree kernel module dependencies, I guess we would need > to construct a union of all outputs so we can pass along one value for > LINUX_MODULE_DIRECTORY that contains all out-of-tree modules that might > be needed for one invocation of modprobe. That sounds like a strange special-casing of out-of-tree modules. What prevents us from presenting the union as /run/current-system/kernel/lib/modules in the first place? That would allow everyone, including all programs on the system and the initrd, to use all modules. Them being in-tree or out-of-tree is a technical detail that should be of no technical consequence to anyone. I suggest to add a field to the operating-system declaration that lists all the packages that contain loadable kernel modules. We could also just make operating-system-kernel be a list--which would be the most direct way I guess. After all, "the" kernel consists of all those modules and the zImage--also in RAM in kernel space while using the stuff. That said, extensibility would be nice--if services could request what kernel modules to add to the operating-system. P.S. How's that supposed to work with the Hurd? I'd guess they are even more modular than this. If we add kernel modularity, might as well also take into account the Hurd.
pgpD0MgApGu4h.pgp
Description: OpenPGP digital signature
