On Thu, May 21, 2009 at 21:43, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote:
> If there is no child at all, no problem, then the device won't be
> interesting to typical application software anyway.
>
> In many cases, there will be just one child, named like the parent with .0
> appended.
>
> However, we also need to cover the case that there is more than one child.
> Then the attributes of all children need to be evaluated.
We could make something like:
ATTR{$kernel.*/specifier_id}=="0x00a02d"
working.
> BTW, the possible (but luckily highly improbable) case of devices with
> several units of different type poses the question which policy to follow:
> Paranoid = deny access unless all units are of a known good type? Or
> comfortable = grant access if at least one unit is of known good type? (My
> PROGRAM based patch actually implements the comfortable policy, in case that
> wasn't obvious.) The paranoid case may have the serious drawback that
> unknown types would prevent access to known types even if the unknown ones
> are actually harmless to expose.
Yeah, the "comfortable" sounds fine and most useful as a default to me.
> If we keep it that way that udev has to look at children attributes (if this
> is feasible at all), then the policy for this mixed type case would remain
> entirely in userspace. But if we go the route of the 1st variant, i.e. copy
> children properties into parent's attributes, then we need to be either very
> careful to solve it without hard-wiring policy into the kernel, or end up
> with a bias of the kernel part towards one or the other policy.
For USB, we read the raw "descriptor", find all possible interfaces,
get class/subclass/protocol byte values from it, remove the
duplicates, and add the values to colon enclosed strings:
$ /lib/udev/usb_id -x /bus/usb/devices/2-1.1.2 | grep INTER
ID_USB_INTERFACES=:030101:030000:
That way we can easily match on "*:030101:*". Maybe that's an option,
if such information is available at the fw_device, at the time it is
created. That would be the simplest solution for userspace.
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
