From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Richter Date: Wed, 20 Aug 2008 20:57:22 +0000 Subject: Re: udev rules for new firewire driver stack Message-Id: <48AC8532.3050607@s5r6.in-berlin.de> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org David Moore wrote: > On Wed, 2008-08-20 at 21:39 +0200, Stefan Richter wrote: > >> # Set GROUP="video" for some IEEE 1394 device types, driven by the new firewire stack. >> # We cannot use the GROUP directive because the significant device type attributes >> # live in child devices. So change the group after the fact with chgrp. >> >> # IIDC devices: industrial cameras and some webcams >> SUBSYSTEM="firewire", ATTR{specifier_id}="0x00a02d", ATTR{version}="0x00010?",\ >> PROGRAM="/bin/chgrp video /dev/%P" >> >> # AV/C devices: camcorders, set-top boxes, TV sets, various audio devices, and more >> SUBSYSTEM="firewire", ATTR{specifier_id}="0x00a02d", ATTR{version}="0x010001",\ >> PROGRAM="/bin/chgrp video /dev/%P" >> > > I tried playing with rules like this about a year ago, but it didn't > work because the spec_id was only available in the child nodes of the > firewire device, so udev couldn't match on it (see more below). Has > that changed so these work now? This hasn't changed; hence I use chgrp on %P which is the parent. I.e. these rules trigger on fwX.Y events but modify the (then already existing) /dev/fwX file. >> 3.e) Aliases for firewire character devices (symlinks) >> >> Right now no application program is known to exist that would be able to >> make use of aliases of (symlinks to) /dev/fw* character device files. >> However, I spotted the following in udev/rules/redhat/40-redhat.rules: >> >> KERNEL="fw*", PROGRAM="fw_unit_symlinks.sh %k %n", SYMLINK+="$result" >> >> BTW, instead of the KERNEL match, I would recommend a SUBSYSTEM match. >> >> A web search turned up that fw_unit_symlinks.sh looks or looked like >> this: >> > ..... > >> So this will create symlinks like iidc3, sbp2-7, avc5 end the likes. >> These aren't persistent (only unique), because %n will change all the >> time. Since they provide symlinks which encode the types of available >> units on the node, these symlinks may be of (some limited) use in the >> future, provided that they would be available on all distributions. > >> So, all things considered, I think we don't need any of such symlinks at >> all. >> > > Yes, I think it was me who originally came up with this symlink script. > See here: > > https://bugzilla.redhat.com/show_bug.cgi?id$0770 Ah, interesting. > It was created because udev rules could not see the spec_id of the > devices and we wanted to selectively chgrp iidc and avc devices to the > console owner. Thus, this script would create named symlinks and then > udev could simply chgrp based on the filename. > > Now that ACLs are used in Fedora for dealing with console ownership, > this script and its udev rule are probably not very useful to anyone. > > However, for other distributions that may not use ACLs, have you > confirmed that spec_id's are truly visible to udev rules now? The rules mentioned above work for me (Gentoo, no ACLs). The IIDC rule alone is enough for coriander. The AV/C rule and the "Linux Firewire" rule get dvgrab et al going. Instead of chgrp, these rules could also call setfacl or a setfacl wrapper. However, I don't know whether the PROGRAM trick works for all distributions, even though it looks simple enough to me. -- Stefan Richter -===-=--- =--- =-=-- http://arcgraph.de/sr/