El 2026-09-28 19:30, Sören Tempel escribió:
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

Submitted an update to kmod[0] a while ago which fixes this.

References:
[0] https://codeberg.org/guix/guix/pulls/10227

HTH
--
Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
             | GPG: 01DE 145E 35D8 C87E 956E  FEC9 D4C4 4BDA 2C98 C654

"If I destroy you, what business is it of yours ?" (Dark Forest, Liu Cixin)

Attachment: signature.asc
Description: PGP signature

Reply via email to