Hi all,
it appears that somebody added a new FireWire driver stack to Linux
kernel 2.6.22 but forgot to work with upstream udev and distributors
of udev to get suitable udev rules out to the public.
Now that endusers start to notice, I had a look at what might be
required.
1.) SCSI devices run by firewire-sbp2 instead of sbp2
All is fine in this department as far as my testing shows. (I use
Gentoo Linux.) Inspection of current upstream udev shows two small
theoretical deficits:
1.a) udev/extras/path_id/path_id
has got a handle_firewire() which is only called and executed correctly
if the sysfs device path matches */fw-host[0-9]*/*. The new firewire
stack has different parent device names and a one step shorter device
hierarchy. (There is no fw-host device anymore.)
Example /dev/disk/by-path link, ieee1394 stack:
pci-0000:05:04.0-ieee1394-0x00101003ae0001e0:00042c:0000 -> ../../sdd
Same device hooked to the same FireWire controller, firewire stack:
pci-fw4.0-scsi-0:0:0:0 -> ../../sdd
If you ask me, this doesn't matter. In fact you could probably simply
remove handle_firewire() from extras/path_id/path_id because I have no
idea why anybody would be interested in the particular looks of the
by-path symlink. After all, the path of hotpluggable devices changes
all the time.
1.b) udev/extras/rule_generator/75-cd-aliases-generator.rules
There is
# the path of removable devices changes frequently
ACTION=="add", SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules by-id", SYMLINK+="%c"
but I have not bothered to figure out how the CD/DVD-ROM/R/W aliases are
supposed to look like. The 70-persistent-cd.rules which have been
collected on my PC over time are a confusing mess with useless
ENV{ID_PATH} items in it, for both ieee1394 and firewire driven devices.
More interesting would be aliases per ID_SERIAL, and that should be
obtained from ATTRS{ieee1394_id} which is provided by both sbp2 and
firewire-sbp2. Right now, sbp2 uses a slightly different format in this
sysfs attribute per default, but I think I will send a kernel patch to
make the same format the default as in firewire-sbp2.
2.) Networking
udev/extras/rule_generator/75-persistent-net-generator.rules contains a
reference to SUBSYSTEMS=="ieee1394" in order to generate a comment.
I.e. a hypothetical IP-over-1394 driver for the firewire stack (not yet
written) won't get a nice comment over its persistent net rule. This
can be amended when the driver is done. I guess such a rule will turn
out to be something like
SUBSYSTEMS=="firewire", ENV{COMMENT}="Firewire device $attr{guid})"
3.) Most important: Video and audio devices
Users should usually be able to access most if not all /dev/fw[0-9]*
character device files without having to be root.
These device files functionally replace the character device files
/dev/raw1394, /dev/video1394*, /dev/dv1394*. But unlike the single
global /dev/raw1394 and the per-bus /dev/video1394* and per-bus
/dev/dv1394*, firewire-core's character device files are per node.
This offers the opportunity to have finer-grained permissions or
ownership or access control lists, based on device types.
For example, deny access per default, but allow access to a group or to
the owner of the console to character device files which belong to video
and audio devices.
Many if not all current libraw1394 based programs (and this are almost
all FireWire interfacing programs) also require access to the local node.
Alas firewire-core's sysfs interface does not provide any clue whether a
node is local or remote. We can only treat all nodes which show
themselves as Linux nodes as if they were local nodes.
At least that's what I found out so far. So here we go:
3.a) udev/rules/gentoo/40-video.rules
contains
# IEEE1394 (firewire) devices
KERNEL=="dv1394*|video1394*|raw1394*", GROUP="video"
Here one could add
SUBSYSTEM=="firewire", GROUP="video"
or change the existing rule to
KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*", GROUP="video"
Alternatively, if you are keen on device type dependent permissions, use
something like this (in addition to the quoted ieee1394 rule):
--------------- 8< ---------------
# 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"
# libraw1394 clients typically also need access to the local node(s). Alas there is
# no simple way to tell local nodes apart from remote ones; here is a simple hack.
SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video"
--------------- >8 ---------------
Note, libdc1394 based applications don't need the libraw1394 rule. Nor
will hypothetical future programs which access /dev/fw* without help of
libraw1394 need it, unless they want to do nifty things on the local node.
Therefore the libraw1394 rule could perhaps be offloaded into an own rules
file, to be provided by libraw1394 packages.
3.b) udev/rules/suse/40-suse.rules
Same as with Gentoo.
3.c) Fedora
As far as I have heard, Fedora and probably RHEL don't set group
ownership but add an access control list entry, and that one is
dependent on the device type. The console owner is granted access to
IIDC and AV/C devices that way.
The Fedora maintainers should also add access to local nodes, or they
need to modify (fix?) libraw1394 or libraw1394 client applications to
work without access to the local node.
3.d) Others
I have no idea what other distros do with /dev/raw1394 and friends
and thus how their /dev/fw* rules should look like.
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:
--------------- 8< ---------------
#!/bin/sh
SYSFS=/sys
NAME=$1
NUM=$2
for i in "${SYSFS}${DEVPATH}/${NAME}.*/specifier_id"; do
if [ ! -f "$i" ]; then
continue
fi
SPECID="`cat $i`"
if [ $((SPECID)) -eq $((0x00609e)) ]; then
echo -n "sbp2-${NUM} "
elif [ $((SPECID)) -eq $((0x00a02d)) ]; then
SWVER="`cat ${i%/specifier_id}/version`"
if [ $((SWVER)) -ge $((0x100)) -a $((SWVER)) -lt $((0x110)) ]; then
echo -n "iidc${NUM} "
elif [ $((SWVER)) -eq $((0x10001)) ]; then
echo -n "avc${NUM} "
elif [ $((SWVER)) -ge $((0x14000)) -a $((SWVER)) -le $((0x14001)) ]; then
echo -n "vendorfw${NUM} "
fi
fi
done
echo
--------------- >8 ---------------
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.
However, since all existing applications retrieve the device type by
other means (typically per ioctl from firewire-core's config ROM cache
which the application or library then parses on its own) and since
applications need additional device type related information anyway, I
don't see a lot of benefit in these per-type symlinks.
Persistently named symlinks could be created too, for example by this
simple rule:
SUBSYSTEM=="firewire", ATTR{guid}=="0x*", SYMLINK+="firewire/$attr{guid}"
However, this too would provide only marginal benefit. Users could
configure hypothetical future applications (which specialize on the new
firewire interface) to use always a desired
/dev/firewire/0x01234567deadbeef device rather than the ever changing
/dev/fw* devices. However, a userfriendly application will be able to
figure out the right /dev/fw* device for a user-configured GUID on its
own without such a symlink.
So, all things considered, I think we don't need any of such symlinks at
all.
Thanks for your attention. Suggestions and corrections welcome.
--
Stefan Richter
-=====-==--- =--- =-=--
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
