Re: udev rules for new firewire driver stack

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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/