On Thu, May 21, 2009 at 17:18, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote:
> The device capabilities are shown in child
> devices of the actual devices which provide the character device files.
> Hence the charcter device files already exist when the "add" events happen
> from which we get the device type (the so-called unit architecture).
> Therefore the 'PROGRAM=/bin/chgrp...' directive is used instead of a
> simple 'GROUP=...' directive.
> +SUBSYSTEM=="firewire", ATTR{specifier_id}=="0x00a02d", \
> ATTR{version}=="0x00010?", PROGRAM="/bin/chgrp video /dev/%P"
Oh, this breaks all sorts of valid assumptions, like it would break
rules plugging into the real device, get overwritten by a child
device. And we rely on proper permissions applied when the event is
send, and not an unpredictable amount of time later by a child device,
and so on ...
Does the fw driver know at the point it creates the device with the
node, that there are childs to create? And such properties can not be
made available at the device itself? Like for USB, where we have the
raw "descriptor" attribute at the device, which allows us to see all
possible interfaces and apply an user access control list to the node
if a matching interface type is found.
Or maybe delay all uevents until the childs are all created, and send
the events only after that, so the child devices can be seen at the
time the event is sent out. We do that for disks, where all partitions
are fully created, before we send out the events: first for the disk,
and then for all partitions.
We fixed almost all these know issues in other subsystems now and I
would really like to see that solved properly, without chrgrp hacks
like in the rules above. It would hit us back badly, when generic
infrastructure which will expect proper event timing regarding device
properties.
Thanks,
Kay
--
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
