Hi Brice,

I wonder how common it is to pass arguments to the modules explicitly in normal
operation.

I haven't done it often even in other distributions--and I'm a kernel hacker.

See also https://linux.die.net/man/5/modprobe.d for an alternative.

I'm not necessarily against doing it like you do it, but just want to bring up
the possibility of just omitting the functionality and let it be
someone-else's-problem, possibly another guix service that prepares
/etc/modprobe.d with module options and other things (aliases, installation and
removal invocations).

That's also important because Linux tries to (lazy-)autoload modules whenever
possible (via invoking modprobe).  In that case, the argument handling would
be inconsistent between if it was lazy-autoloaded compared to if it was loaded
by your loader.

(I even wonder if it were better for kernel-module-loader-service to read the
modprobe to use from /proc/sys/kernel/modprobe in order to make the situations
a little more consistent)

For example let's say the following happened:

(1) Linux boots up.
(2) Someone accesses some device so "modprobe foo" is invoked by Linux.
(3) foo is loaded, gets options from /etc/modprobe.d (usually none).
[Time passes, other stuff happens]
(4) Your kernel-module-loader-service is started, invokes "modprobe foo x=2".
(5) x=2 is not passed to the Linux kernel module ever.

I'm just saying maybe not invite this kind of trouble in the first place.

I don't think it fits Guix's declarative configuration style to do that
either.

Also, when reconfiguring the Guix system, kernel-module-loader-service won't
unload the kernel modules and thus also wouldn't load it with new options.

Also, it could happen that two different guix services require the same module
but with different options.  That's an insane problem to have and I wouldn't
try to support it.

(I've reviewed your patch, otherwise OK!)