Stefan Richter wrote:
fw_device is the parent which is
associated with a character device file, fw_unit are the children. In
principle, fw_unit's could come and go at any point during the lifetime
of an fw_device, but for simplicity's sake our implementation destroys
and fw_device if a unit went away or was added on the respective
FireWire node, and a new fw_device is created in its stead.
Err, no, I remembered wrong, even though I wrote parts of the respective
code myself... The fw_device /stays there/, while fw_units may come or
go later during the fw_device's lifetime. This happens when the device
signals us that its configuration has changed; we then re-read the
configuration and destroy/ create fw_units.
(The only restriction of the current implementation is that we don't
fully compare the old and new configuration to find out whether previous
fw_units are still there after such a change; we simply destroy all
previous fw_units and freshly create all current fw_units.)
However, I know of no device which actually does this, except for PC OSs
like Linux when unit architecture drivers are loaded while its 1394
driver stack is already life (e.g. the Linux userspace driver Endpoint
which is an SBP-2 target, ditto the eth1394 kernel driver, there have
also been & are plans for AV/C target drivers --- i.e. audio or video
devices for which we want group assignments and/or ACLs being updated).
So, it's currently a scenario of low practical relevance, but userspace
should be enabled to react on it.
From what I remember how Fedora's symlinking solution works (which
serves two purposes: create file aliases with names more meaningful
than plain /dev/fw*; but more importantly, update the ACL of the device
file behind the symlink), it works the same regardless whether a unit
pops up 1 nanosecond or 1 day after addition of the fw_device.
I'm not sure though how to proceed for an "upstream" solution. The
Fedora mechanism is surely nice, but it isn't very compact (involves an
extra script and the infrastructure & policy files to set ACLs for the
console owner) and does not cover the use case of Unix group ownership.
Would it work if I implement the discussed aggregate fw_device attribute
(i.e. the concatenation of significant attributes of all children) and
send an KOBJ_CHANGE event when units were recreated? Do change events
trigger the necessary actions to update ownership and ACL?
One other thing which I forgot yesterday:
We actually already have an attribute which exists when an fw_device
KOBJ_ADD event happens and includes information about all children.
However, it is a binary blob (config_rom, a dump of the device
description from which also ATTR{specifier_id} and ATTR{version} are
derived; format is defined in IEEE 1212, contents defined in various
higher level protocol specs) --- and since the firewire-core has a
config ROM parser anyway, we do not really want to duplicate this parser
in userspace for basic purposes like setting device file ownership/
ACLs/ symlinks and the likes.
--
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
