[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Brice Waegeneire
Subject: [bug#40274] [PATCH v5] gnu: Add kernel-module-loader-service.
Date: Thu, 02 Apr 2020 17:13:05 +0000
User-agent: Roundcube Webmail/1.3.8

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

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

See also 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

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
                (module "acpi-call")
                (blacklist? #t))))

- Brice

reply via email to

[Prev in Thread] Current Thread [Next in Thread]