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.

Attachment: pgpD0MgApGu4h.pgp
Description: OpenPGP digital signature

Reply via email to