all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Daniel Pimentel <d4n1@d4n1.org>, help-guix@gnu.org
Subject: udev rules and system configuration (was: Microscheme failed)
Date: Mon, 04 Jul 2016 16:55:56 +0200	[thread overview]
Message-ID: <87shvpe9kz.fsf@elephly.net> (raw)
In-Reply-To: <87inwlhlgv.fsf@gnu.org>


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.

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.

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.

~~ Ricardo

  reply	other threads:[~2016-07-04 14:56 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     ` Ricardo Wurmus [this message]
2016-07-04 15:46       ` udev rules and system configuration Ludovic Courtès
2016-07-04 18:05         ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87shvpe9kz.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=d4n1@d4n1.org \
    --cc=help-guix@gnu.org \
    --cc=ludo@gnu.org \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.