guix-devel
[Top][All Lists]
Advanced

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

Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".


From: Ludovic Courtès
Subject: Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Date: Tue, 07 Apr 2020 11:35:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hi,

Brice Waegeneire <address@hidden> skribis:

> On 2020-04-05 21:15, Ludovic Courtès wrote:
>> address@hidden skribis:
>>>                    #~(begin
>>>                        (setenv "LINUX_MODULE_DIRECTORY"
>>>                                "/run/booted-system/kernel/lib/modules")
>>> +                      ;; FIXME: Remove this crutch when the patch
>>> #40422,
>>> +                      ;; updating to kmod 27 is merged.
>>> +                      (setenv "MODPROBE_OPTIONS"
>>> +                              "-C /etc/modprobe.d")
>>
>> [...]
>>
>>> +  (services (cons* (service kernel-module-loader-service-type
>>> +                            '("ddcci" "ddcci_backlight"))
>>> +                   (simple-service 'ddcci-config etc-service-type
>>> +                                   (list `("modprobe.d/ddcci.conf"
>>> +                                           ,ddcci-config)))
>>> +                   %base-services))
>>
>> Looking at this, I was wondering if it would be possible to not use
>> /etc/modprobe.d and instead have a way to tell the modprobe wrapper to
>> pass “-C /gnu/store/…-modprobe.d”, which would contain the right thing.
>>
>> Thoughts?
>
> What's the issue with using /etc/modrpobe.d?

In general, use of the global file system name space isn’t great: it’s
ambiguous (compare to a /gnu/store reference) and doesn’t work well upon
rollback or reconfigure (things that refer to /etc end up referring to
the “new” /etc after reconfigure, even though that might not actually
work.)

Conversely, “-C /gnu/store/…-modprobe.d” unambiguously refers to the
intended directory.

WDYT?

> As noted in the comments I thought setting MODPROBE_OPTIONS was kinda
> of a
> hack; #40422[0] was there to fix it. But if you think it's appropriate
> to
> use this environment variable it can be done in a future
> “kernel-module-configuration-service-type” we discussed with Danny[1].

Sure, no problem!

> Instead of extending “etc-service-type” we would use
> “activation-service-type”, as “%modprobe-wrapper” is currently put
> in place by a simple activation service.

Makes sense.

Thank you,
Ludo’.



reply via email to

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