[bug#40274] [PATCH v5] gnu: Add kernel-module-loader-service.

[Brice Waegeneire <brice@waegenei.re>]

On 2020-04-02 13:56, Danny Milosavljevic wrote:
> 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!)
Hello Danny,

Thank for taking the time to review this patch. Since I'm definitely 
*not*
a kernel hacker --just a casual user-- I wasn't aware of the uselessness 
of
specifying the module arguments to modprobe in such service. I wrote 
this
patch just to load this pesky non auto-loading `ddcci-backlight` module 
and
I have no current use of specifying module arguments. I just thought it
*could* be useful, to some, to pass arguments to modprobe since it is
present in its API; but the edge-cases you brought up show that it 
wasn't a
good idea after all.

Should I just go back to the first format, with just a list of module
names, and we merge this patch? Or would it be better, regarding the 
user
interface, to start this patch anew by using `modprobe.d` API as a base.
By that I mean defining a `modprobe-service-type` which populates
`/etc/modprobe.d/` and can manually load a module at boot if needed 
(like
kernel-module-loader does)? Would it be overkill? Following is an 
example of
what such service could look like:

#+begin_src scheme
(service modprobe-service-type
          (list (modprobe-entry
                 (module "ddcci")
                 (load? #t)
                 (options '("dyndbg" "delay=120"))
                 (alises '("ddc/ci"))
                 (install "")           ; default
                 (remove ""))           ; default
                (modprobe-entry
                 (module "acpi-call")
                 (blacklist? #t))))
#+end_src

- Brice