From: ludo@gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado@elephly.net>
Cc: Daniel Pimentel <d4n1@d4n1.org>, help-guix@gnu.org
Subject: Re: udev rules and system configuration
Date: Mon, 04 Jul 2016 17:46:20 +0200 [thread overview]
Message-ID: <87inwlbe43.fsf@gnu.org> (raw)
In-Reply-To: <87shvpe9kz.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 04 Jul 2016 16:55:56 +0200")
Ricardo Wurmus <rekado@elephly.net> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello!
>>
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>
>>> For my AVR programmers I have this in my system configuration:
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> (define avrispmkii-udev-rule
>>> (udev-rule "90-avrispmkii.rules"
>>> "\
>>> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
>>>
>>> # Atmel Corp. JTAG ICE mkII
>>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", GROUP=\"dialout\"
>>> # Atmel Corp. AVRISP mkII
>>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", GROUP=\"dialout\"
>>> # Atmel Corp. Dragon
>>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", GROUP=\"dialout\"
>>>
>>> LABEL=\"avrisp_end\"\n"))
>>>
>>> (operating-system
>>> …
>>> (services (cons* (modify-services %desktop-services
>>> (udev-service-type config =>
>>> (udev-configuration
>>> (inherit config)
>>> (rules (append (udev-configuration-rules config)
>>> (list avrispmkii-udev-rule))))))))
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Should we add this as an optional service or to the default set of udev
>> rules?
>
> I don’t think this should be the default. This rule is only useful for
> those who own one of Atmel’s USB programmer devices. There is a
> multitude of programmers for AVRs and users may want to use different
> rules for different devices.
>
> However, I’ve been wondering if we shouldn’t introduce nicer
> abstractions for udev rules and make loading them a little less verbose.
> It’s a bit unfortunate that while on other systems users are often told
> to just dump a file somewhere in “/etc” to make device access work
> without root on GuixSD it’s quite a bit more involved to achieve the
> same.
Yeah, it doesn’t support the quick-hack style of doing things, which can
be frustrating.
> Our documentation is also a little lacking in this respect. The manual
> has very little to say about the “udev-service” and how to extend it (or
> any of the other services, really), making it hard for users coming from
> other systems to find where they need to change something to make the
> udev rules work that they were told to add somewhere.
Yeah.
> 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.
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")
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 deny that this is still more heavyweight than dropping a file in
/etc. We should think about other ways to improve on that (what would
be the equivalent of C-M-x for GuixSD?), but for now it’s the only way I
can think of to preserve reproducibility.
Ludo’.
next prev parent reply other threads:[~2016-07-04 15:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-03 22:12 Microscheme failed Daniel Pimentel
2016-07-04 6:14 ` Ricardo Wurmus
2016-07-04 8:10 ` Ludovic Courtès
2016-07-04 14:55 ` udev rules and system configuration (was: Microscheme failed) Ricardo Wurmus
2016-07-04 15:46 ` Ludovic Courtès [this message]
2016-07-04 18:05 ` udev rules and system configuration Ricardo Wurmus
2016-07-05 8:34 ` Ludovic Courtès
2016-07-14 14:22 ` Microscheme failed Daniel Pimentel
2016-07-04 12:30 ` Daniel Pimentel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inwlbe43.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=d4n1@d4n1.org \
--cc=help-guix@gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).