Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hello, On 2020-04-07 09:35, Ludovic Courtès wrote: Brice Waegeneire skribis: On 2020-04-05 21:15, Ludovic Courtès wrote: guix-comm...@gnu.org skribis: 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? It's good with me, I'll do as suggested -using the environment variable- when implementing “kernel-module-configuratuion-service-type”. - Brice
Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hello Bengt, On 2020-04-06 09:29, Bengt Richter wrote: On +2020-04-06 07:54:47 +, Brice Waegeneire wrote: What's the issue with using /etc/modrpobe.d? I would think the fundamental issue is pure vs impure dependencies: i.e., /gnu/... vs /var/guix vs /elsewhere/... IIUC, the consequence of using /etc/... or ~/... or other non-/gnu/... is that if you want to run something in a container with chrooted root, you have to cow-fake /etc and all the rest of non-/gnu/... environment, so your executable is not as generally usable as possible if nuisance adjustments were not necessary. People who might want to use it anyway have to think about a bunch of stuff not relevant to what they actually want to do -- they will wind up debugging functionally-irrelevant implementation stuff. Maybe I misunderstand, but are you and Ludo on the same page re the fundamental concept of guix and how it plays in various contexts? (allowing for "practicality beats purity"[1] when absolutely necessary ;-) Yes, only the reason why to do it was eluding me. I'll keep in mind your rule thumb. - Brice
Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hi, Brice Waegeneire skribis: > On 2020-04-05 21:15, Ludovic Courtès wrote: >> guix-comm...@gnu.org 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’.
Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hi Brice, Ludo, On +2020-04-06 07:54:47 +, Brice Waegeneire wrote: > Hello Ludo', > > On 2020-04-05 21:15, Ludovic Courtès wrote: > > guix-comm...@gnu.org 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? > I would think the fundamental issue is pure vs impure dependencies: i.e., /gnu/... vs /var/guix vs /elsewhere/... IIUC, the consequence of using /etc/... or ~/... or other non-/gnu/... is that if you want to run something in a container with chrooted root, you have to cow-fake /etc and all the rest of non-/gnu/... environment, so your executable is not as generally usable as possible if nuisance adjustments were not necessary. People who might want to use it anyway have to think about a bunch of stuff not relevant to what they actually want to do -- they will wind up debugging functionally-irrelevant implementation stuff. Maybe I misunderstand, but are you and Ludo on the same page re the fundamental concept of guix and how it plays in various contexts? (allowing for "practicality beats purity"[1] when absolutely necessary ;-) > 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]. > 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. > > [0]: https://issues.guix.info/issue/40422 > [1]: https://issues.guix.info/issue/40274#29 > > - Brice > [1] python -c 'import this' -- Regards, Bengt Richter
Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hello Ludo', On 2020-04-05 21:15, Ludovic Courtès wrote: guix-comm...@gnu.org 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? 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]. 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. [0]: https://issues.guix.info/issue/40422 [1]: https://issues.guix.info/issue/40274#29 - Brice
Re: 01/02: services: Allow modprobe to use "/etc/modprobe.d".
Hi Danny & Brice, Nice stuff! guix-comm...@gnu.org skribis: > --- a/gnu/services.scm > +++ b/gnu/services.scm > @@ -580,6 +580,10 @@ ACTIVATION-SCRIPT-TYPE." >#~(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? Ludo’.