guix-patches
[Top][All Lists]
Advanced

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

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


From: Danny Milosavljevic
Subject: [bug#40274] [PATCH v5] gnu: Add kernel-module-loader-service.
Date: Fri, 3 Apr 2020 12:20:44 +0200

Hi Brice,

On Thu, 02 Apr 2020 17:13:05 +0000
Brice Waegeneire <address@hidden> wrote:

> *could* be useful, to some, to pass arguments to modprobe since it is
> present in its API; 

Definitely could be useful.  The question is whether the complexity justifies it
and whether it can be reliable.

> Should I just go back to the first format, with just a list of module
> names, and we merge this patch? 

I would like that more since it's very improbable to ever need changing.

>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:

I think the two things (loading a module and configuring a module) can be
seperate, so I wouldn't mix it.

For example why would you load a module before the service that needs
it actually starts up (if ever)?  That just increases the attack surface 
for no reason.  On the other hand, module configuration will probably be
done as part of some guix service presence--used or not.

That said, maybe there are upsides to--among other things easier-understandable
configuration if it's central.

> #+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))))

A service to do that would still be nice.  But maybe
"kernel-module-configuration-service" ?

(Please don't think I have all the answers, let's see which way is better)

Attachment: pgpUVOwwX1f8I.pgp
Description: OpenPGP digital signature


reply via email to

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