From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: udev rules and system configuration Date: Mon, 04 Jul 2016 17:46:20 +0200 Message-ID: <87inwlbe43.fsf@gnu.org> References: <448fd23bfc5b716dadbaf46aac1b85ce@d4n1.org> <87vb0mdj4w.fsf@elephly.net> <87inwlhlgv.fsf@gnu.org> <87shvpe9kz.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bK64q-0001VZ-MJ for help-guix@gnu.org; Mon, 04 Jul 2016 11:46:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bK64m-0004SB-GQ for help-guix@gnu.org; Mon, 04 Jul 2016 11:46:27 -0400 In-Reply-To: <87shvpe9kz.fsf@elephly.net> (Ricardo Wurmus's message of "Mon, 04 Jul 2016 16:55:56 +0200") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Ricardo Wurmus Cc: Daniel Pimentel , help-guix@gnu.org Ricardo Wurmus skribis: > Ludovic Court=C3=A8s writes: > >> Hello! >> >> Ricardo Wurmus skribis: >> >>> For my AVR programmers I have this in my system configuration: >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> (define avrispmkii-udev-rule >>> (udev-rule "90-avrispmkii.rules" >>> "\ >>> SUBSYSTEM!=3D\"usb\", ACTION!=3D\"add\", GOTO=3D\"avrisp_end\" >>> >>> # Atmel Corp. JTAG ICE mkII >>> ATTR{idVendor}=3D=3D\"03eb\", ATTR{idProduct}=3D=3D\"2103\", MODE=3D\"6= 60\", GROUP=3D\"dialout\" >>> # Atmel Corp. AVRISP mkII >>> ATTR{idVendor}=3D=3D\"03eb\", ATTR{idProduct}=3D=3D\"2104\", MODE=3D\"6= 60\", GROUP=3D\"dialout\" >>> # Atmel Corp. Dragon >>> ATTR{idVendor}=3D=3D\"03eb\", ATTR{idProduct}=3D=3D\"2107\", MODE=3D\"6= 60\", GROUP=3D\"dialout\" >>> >>> LABEL=3D\"avrisp_end\"\n")) >>> >>> (operating-system >>> =E2=80=A6 >>> (services (cons* (modify-services %desktop-services >>> (udev-service-type config =3D> >>> (udev-configuration >>> (inherit config) >>> (rules (append (udev-configura= tion-rules config) >>> (list avrispmki= i-udev-rule)))))))) >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> Should we add this as an optional service or to the default set of udev >> rules? > > I don=E2=80=99t think this should be the default. This rule is only usef= ul for > those who own one of Atmel=E2=80=99s USB programmer devices. There is a > multitude of programmers for AVRs and users may want to use different > rules for different devices. > > However, I=E2=80=99ve been wondering if we shouldn=E2=80=99t introduce ni= cer > abstractions for udev rules and make loading them a little less verbose. > It=E2=80=99s a bit unfortunate that while on other systems users are ofte= n told > to just dump a file somewhere in =E2=80=9C/etc=E2=80=9D to make device ac= cess work > without root on GuixSD it=E2=80=99s quite a bit more involved to achieve = the > same. Yeah, it doesn=E2=80=99t support the quick-hack style of doing things, whic= h can be frustrating. > Our documentation is also a little lacking in this respect. The manual > has very little to say about the =E2=80=9Cudev-service=E2=80=9D and how t= o 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=E2=80=99s 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 =E2=80=9C/etc/guix/system/udev/rules.d=E2= =80=9D then all > files therein would automatically be considered part of the system > configuration, maybe after adding =E2=80=9C/etc/guix/system=E2=80=9D as a= prefix path to > some new field in the =E2=80=9Coperating-system=E2=80=9D 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 > =E2=80=9C/etc/config.scm=E2=80=9D and modifying services manually. It=E2=80=99s 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=E2=80=99t be enough to return to the previous state, copying the GuixSD config file wouldn=E2=80=99t 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 =E2=80=98udev-rule=E2=80=99 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 =E2=80=98extra-udev-rule=E2=80=99 procedure that you could use l= ike this: (operating-system ;; =E2=80=A6 (services (extra-udev-rule (local-file "./my-udev-rule")) =E2=80=A6)) thus avoiding the verbose =E2=80=98modify-services=E2=80=99 stanza. 3. (Instead of #2) Introduce a =E2=80=98udev-rules=E2=80=99 field in =E2=80=98operating-system=E2=80=99, just like we do for firmware. WDYT? I don=E2=80=99t deny that this is still more heavyweight than dropping a fi= le 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=E2=80=99s the only = way I can think of to preserve reproducibility. Ludo=E2=80=99.