Hello there!
On 2020-04-07 11:35, Ludovic Courtès wrote:
>> On 2020-04-05 21:15, Ludovic Courtès wrote:
>>> Brice Waegeneire 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.
I think >6 years later, I discovered a limitation of this approach,
which eventually ended up being merged [1]. If a kernel module is loaded
directly through kmod's API, then the "modprobe wrapper" proposed here
is not used and the kernel module configuration is not picked up.
This, for example, happens when a module is loaded by eudev [2]. The kmod
API /does/ consult @sysconfdir@/etc but, because @sysconfdir@ refers to
the store, it does not consult /etc/modprobe.d. As such, it is AFAIK
impossible to set options for kernel modules that are loaded by eudev
using our existing kernel-module-loader-service-type infrastructure.
Also note that we still advise storing kernel module configuration in
/etc/modprobe.d in our docs [3]. I would argue we thus still end up
using it as a "global file system name". I would thus suggest that we
reconsider configuring kmod with --sysconfdir=/etc. This is also how it
is implemented in nixpkgs [4]. Would it be possible to revisit this?
See also: https://codeberg.org/guix/guix/issues/11378
Cheers,
Sören
[1]:
https://codeberg.org/guix/guix/commit/044d1478c9a63a64547c9cc320008f8d8fbf6791
[2]:
https://github.com/eudev-project/eudev/blob/aa49f5cc7e3959b297b9355c72067776d238d5d0/src/udev/udev-builtin-kmod.c
[3]:
https://guix.gnu.org/manual/devel/en/html_node/Linux-Services.html#index-kernel_002dmodule_002dloader_002dservice_002dtype
[4]:
https://github.com/NixOS/nixpkgs/blob/6d663c0533ff269008fb84e45930151e37c99db9/pkgs/os-specific/linux/kmod/default.nix#L81
