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’.
