Re: udev rules and system configuration

[Ricardo Wurmus <rekado@elephly.net>]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:

>> Here’s an idea, which might be bad: how about adding a feature to load
>> and merge a directory tree of configuration files as they are?  For
>> example, if I had a directory “/etc/guix/system/udev/rules.d” then all
>> files therein would automatically be considered part of the system
>> configuration, maybe after adding “/etc/guix/system” as a prefix path to
>> some new field in the “operating-system” declaration.
>>
>> I have a feeling that this will be considered a bad idea, but it also
>> seems to me that it would make the configuration of some parts of the
>> system easier than embedding file contents as strings in variables in
>> “/etc/config.scm” and modifying services manually.
>
> It’s a bad idea!  :-)
>
> Seriously, I think having a directory that is automatically picked up is
> a bad idea in the sense that it would defeat one of the main goals of
> GuixSD, which is to support reproducibility.  The hypothetical
> /etc/guix/udev directory would not be controlled by GuixSD, so rolling
> back wouldn’t be enough to return to the previous state, copying the
> GuixSD config file wouldn’t be enough to duplicate the system state on
> another machine, and so on.

These files are not loaded at system runtime but upon running “guix
system reconfigure”.  Their contents *at that time* would be embedded in
the configuration.  Their state *at runtime* would not matter (just like
the contents of “config.scm” don’t matter at runtime).

The files would become part of the configuration in the store.  Changing
them would always require the additional step of reconfiguring the
system.

> However, what we can do is improve the interface.  Things that come to
> mind:
>
>   1. Change or remove the ‘udev-rule’ procedure; we should be using
>      file-like objects instead, so one could store them alongside
>      config.scm and write:
>
>        (local-file "./my-udev-rule")

Is this really so different from the bad idea I proposed?  As soon as we
load files outside of “config.scm” users would need to copy more than
just the GuixSD config file to duplicate the system state on another
machine.  In this example we would need both “config.scm” and
“my-udev-rule” in the same directory.

The bad idea still requires a user to tell Guix to load udev rule files
from somewhere.  The difference is that instead of loading files
individually by name it would load *all* rules from the directory.

I guess it’s not very different form what you propose in #3, actually.

>   2. Add a ‘extra-udev-rule’ procedure that you could use like this:
>
>        (operating-system
>          ;; …
>          (services (extra-udev-rule (local-file "./my-udev-rule"))
>                    …))
>
>      thus avoiding the verbose ‘modify-services’ stanza.
>
>   3. (Instead of #2) Introduce a ‘udev-rules’ field in
>      ‘operating-system’, just like we do for firmware.
>
> WDYT?

I don’t know.  Although this would simplify configuration I don’t really
like either of them for somewhat conflicting reasons.  #3 gives special
treatment to udev rules (“What about Xorg config snippets?”), and with
#2 it seems like an unnecessary implementation detail that this
“extra-udev-rule” procedure is inside of the “services” field (“How come
this is a service?”).

I also feel that we should avoid adding “special” syntax.  Actually, I
really like how generic this whole “modify-services” business is.  It’s
just a little too verbose to be user-friendly, in my opinion.

~~ Ricardo