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

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

[Ludovic Courtès]

Hi Danny & Brice,

Nice stuff!

guix-commits@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’.

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

[Brice Waegeneire]

Hello Ludo',

On 2020-04-05 21:15, Ludovic Courtès wrote:
> guix-commits@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".

[Bengt Richter]

Hi Brice, Ludo,

On +2020-04-06 07:54:47 +0000, Brice Waegeneire wrote:
> Hello Ludo',
> 
> On 2020-04-05 21:15, Ludovic Courtès wrote:
> > guix-commits@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".

[Ludovic Courtès]

Hi,

Brice Waegeneire <brice@waegenei.re> skribis:

> On 2020-04-05 21:15, Ludovic Courtès wrote:
>> guix-commits@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".

[Brice Waegeneire]

Hello Bengt,

On 2020-04-06 09:29, Bengt Richter wrote:
> On +2020-04-06 07:54:47 +0000, 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".

[Brice Waegeneire]

Hello,

On 2020-04-07 09:35, Ludovic Courtès wrote:
> Brice Waegeneire <brice@waegenei.re> skribis:
>> On 2020-04-05 21:15, Ludovic Courtès wrote:
>>> guix-commits@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