All of lore.kernel.org
 help / color / mirror / Atom feed
* Use GROUP= in a rule matching an interface of the device?
@ 2010-09-09  9:21 Ludovic Rousseau
  2010-09-09  9:36 ` Kay Sievers
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: Ludovic Rousseau @ 2010-09-09  9:21 UTC (permalink / raw)
  To: linux-hotplug

Hello,

I am trying to write a udev configuration file to change the group
ownership of the device if the device contains a CCID interface
(bInterfaceClass = 11 or 0x0B).

I would like to use something like:
ATTR{bInterfaceClass}="0b", GROUP="pcscd"
but that does not work.

I also tried ATTRS instead of ATTR
ATTRS{bInterfaceClass}="0b", GROUP="pcscd"
but it does not work either.

One solution I found to work is:
ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"


It looks like the problem is that my rule matches on an attribute of
an interface instead of an attribute of the device.
Is it possible/supported to use GROUP= in my case?

Thanks

Some more info:
Debian testing/squeeze system
kernel 2.6.34-1-686
udev 160-1

$ udevadm monitor --env --kernel --udev

KERNEL[1284023092.630235] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1 (usb)
UDEV_LOG=3
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1
SUBSYSTEM=usb
DEVNAME=bus/usb/003/035
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
BUSNUM\03
DEVNUM\x035
SEQNUM\x1538
MAJOR\x189
MINOR)0

KERNEL[1284023092.633197] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0 (usb)
UDEV_LOG=3
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
INTERFACE\x11/0/0
MODALIAS=usb:v08E6p3437d0100dc00dsc00dp00ic0Bisc00ip00
SEQNUM\x1539

UDEV  [1284023092.642405] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1 (usb)
UDEV_LOG=3
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/003/035
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
BUSNUM\03
DEVNUM\x035
SEQNUM\x1538
ID_VENDOR=Gemplus
ID_VENDOR_ENC=Gemplus
ID_VENDOR_ID\be6
ID_MODEL=USB_SmartCard_Reader
ID_MODEL_ENC=USB\x20SmartCard\x20Reader
ID_MODEL_ID437
ID_REVISION\x0100
ID_SERIAL=Gemplus_USB_SmartCard_Reader
ID_BUS=usb
ID_USB_INTERFACES=:0b0000:
MAJOR\x189
MINOR)0
DEVLINKS=/dev/char/189:290

UDEV  [1284023092.663831] add
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0 (usb)
UDEV_LOG=3
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/003/035
PRODUCTŽ6/3437/100
TYPE=0/0/0
INTERFACE\x11/0/0
MODALIAS=usb:v08E6p3437d0100dc00dsc00dp00ic0Bisc00ip00
SEQNUM\x1539


$ udevadm info --path /devices/pci0000:00/0000:00:1d.1/usb3/3-1 --attribute-walk

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
    KERNEL="3-1"
    SUBSYSTEM="usb"
    DRIVER="usb"
    ATTR{configuration}=""
    ATTR{bNumInterfaces}=" 1"
    ATTR{bConfigurationValue}="1"
    ATTR{bmAttributes}="e0"
    ATTR{bMaxPower}="100mA"
    ATTR{urbnum}="756"
    ATTR{idVendor}="04cc"
    ATTR{idProduct}="1122"
    ATTR{bcdDevice}="0110"
    ATTR{bDeviceClass}="09"
    ATTR{bDeviceSubClass}="00"
    ATTR{bDeviceProtocol}="00"
    ATTR{bNumConfigurations}="1"
    ATTR{bMaxPacketSize0}="64"
    ATTR{speed}="12"
    ATTR{busnum}="3"
    ATTR{devnum}="2"
    ATTR{devpath}="1"
    ATTR{version}=" 1.10"
    ATTR{maxchild}="5"
    ATTR{quirks}="0x0"
    ATTR{avoid_reset_quirk}="0"
    ATTR{authorized}="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3':
    KERNELS="usb3"
    SUBSYSTEMS="usb"
    DRIVERS="usb"
    ATTRS{configuration}=""
    ATTRS{bNumInterfaces}=" 1"
    ATTRS{bConfigurationValue}="1"
    ATTRS{bmAttributes}="e0"
    ATTRS{bMaxPower}="  0mA"
    ATTRS{urbnum}="34"
    ATTRS{idVendor}="1d6b"
    ATTRS{idProduct}="0001"
    ATTRS{bcdDevice}="0206"
    ATTRS{bDeviceClass}="09"
    ATTRS{bDeviceSubClass}="00"
    ATTRS{bDeviceProtocol}="00"
    ATTRS{bNumConfigurations}="1"
    ATTRS{bMaxPacketSize0}="64"
    ATTRS{speed}="12"
    ATTRS{busnum}="3"
    ATTRS{devnum}="1"
    ATTRS{devpath}="0"
    ATTRS{version}=" 1.10"
    ATTRS{maxchild}="2"
    ATTRS{quirks}="0x0"
    ATTRS{avoid_reset_quirk}="0"
    ATTRS{authorized}="1"
    ATTRS{manufacturer}="Linux 2.6.34-1-686 uhci_hcd"
    ATTRS{product}="UHCI Host Controller"
    ATTRS{serial}="0000:00:1d.1"
    ATTRS{authorized_default}="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.1':
    KERNELS="0000:00:1d.1"
    SUBSYSTEMS="pci"
    DRIVERS="uhci_hcd"
    ATTRS{vendor}="0x8086"
    ATTRS{device}="0x27c9"
    ATTRS{subsystem_vendor}="0x1028"
    ATTRS{subsystem_device}="0x01ad"
    ATTRS{class}="0x0c0300"
    ATTRS{irq}="22"
    ATTRS{local_cpus}="ffffffff"
    ATTRS{local_cpulist}="0-31"
    ATTRS{modalias}="pci:v00008086d000027C9sv00001028sd000001ADbc0Csc03i00"
    ATTRS{dma_mask_bits}="32"
    ATTRS{consistent_dma_mask_bits}="32"
    ATTRS{broken_parity_status}="0"
    ATTRS{msi_bus}=""

  looking at parent device '/devices/pci0000:00':
    KERNELS="pci0000:00"
    SUBSYSTEMS=""
    DRIVERS=""


$ udevadm info --path
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0
--attribute-walk

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0':
    KERNEL="3-1.1:1.0"
    SUBSYSTEM="usb"
    DRIVER=""
    ATTR{bInterfaceNumber}="00"
    ATTR{bAlternateSetting}=" 0"
    ATTR{bNumEndpoints}="03"
    ATTR{bInterfaceClass}="0b"
    ATTR{bInterfaceSubClass}="00"
    ATTR{bInterfaceProtocol}="00"
    ATTR{modalias}="usb:v08E6p3437d0100dc00dsc00dp00ic0Bisc00ip00"
    ATTR{supports_autosuspend}="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1':
    KERNELS="3-1.1"
    SUBSYSTEMS="usb"
    DRIVERS="usb"
    ATTRS{configuration}=""
    ATTRS{bNumInterfaces}=" 1"
    ATTRS{bConfigurationValue}="1"
    ATTRS{bmAttributes}="a0"
    ATTRS{bMaxPower}="200mA"
    ATTRS{urbnum}="9"
    ATTRS{idVendor}="08e6"
    ATTRS{idProduct}="3437"
    ATTRS{bcdDevice}="0100"
    ATTRS{bDeviceClass}="00"
    ATTRS{bDeviceSubClass}="00"
    ATTRS{bDeviceProtocol}="00"
    ATTRS{bNumConfigurations}="1"
    ATTRS{bMaxPacketSize0}="8"
    ATTRS{speed}="12"
    ATTRS{busnum}="3"
    ATTRS{devnum}="35"
    ATTRS{devpath}="1.1"
    ATTRS{version}=" 1.10"
    ATTRS{maxchild}="0"
    ATTRS{quirks}="0x0"
    ATTRS{avoid_reset_quirk}="0"
    ATTRS{authorized}="1"
    ATTRS{manufacturer}="Gemplus"
    ATTRS{product}="USB SmartCard Reader"

  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
    KERNELS="3-1"
    SUBSYSTEMS="usb"
    DRIVERS="usb"
    ATTRS{configuration}=""
    ATTRS{bNumInterfaces}=" 1"
    ATTRS{bConfigurationValue}="1"
    ATTRS{bmAttributes}="e0"
    ATTRS{bMaxPower}="100mA"
    ATTRS{urbnum}="756"
    ATTRS{idVendor}="04cc"
    ATTRS{idProduct}="1122"
    ATTRS{bcdDevice}="0110"
    ATTRS{bDeviceClass}="09"
    ATTRS{bDeviceSubClass}="00"
    ATTRS{bDeviceProtocol}="00"
    ATTRS{bNumConfigurations}="1"
    ATTRS{bMaxPacketSize0}="64"
    ATTRS{speed}="12"
    ATTRS{busnum}="3"
    ATTRS{devnum}="2"
    ATTRS{devpath}="1"
    ATTRS{version}=" 1.10"
    ATTRS{maxchild}="5"
    ATTRS{quirks}="0x0"
    ATTRS{avoid_reset_quirk}="0"
    ATTRS{authorized}="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb3':
    KERNELS="usb3"
    SUBSYSTEMS="usb"
    DRIVERS="usb"
    ATTRS{configuration}=""
    ATTRS{bNumInterfaces}=" 1"
    ATTRS{bConfigurationValue}="1"
    ATTRS{bmAttributes}="e0"
    ATTRS{bMaxPower}="  0mA"
    ATTRS{urbnum}="34"
    ATTRS{idVendor}="1d6b"
    ATTRS{idProduct}="0001"
    ATTRS{bcdDevice}="0206"
    ATTRS{bDeviceClass}="09"
    ATTRS{bDeviceSubClass}="00"
    ATTRS{bDeviceProtocol}="00"
    ATTRS{bNumConfigurations}="1"
    ATTRS{bMaxPacketSize0}="64"
    ATTRS{speed}="12"
    ATTRS{busnum}="3"
    ATTRS{devnum}="1"
    ATTRS{devpath}="0"
    ATTRS{version}=" 1.10"
    ATTRS{maxchild}="2"
    ATTRS{quirks}="0x0"
    ATTRS{avoid_reset_quirk}="0"
    ATTRS{authorized}="1"
    ATTRS{manufacturer}="Linux 2.6.34-1-686 uhci_hcd"
    ATTRS{product}="UHCI Host Controller"
    ATTRS{serial}="0000:00:1d.1"
    ATTRS{authorized_default}="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.1':
    KERNELS="0000:00:1d.1"
    SUBSYSTEMS="pci"
    DRIVERS="uhci_hcd"
    ATTRS{vendor}="0x8086"
    ATTRS{device}="0x27c9"
    ATTRS{subsystem_vendor}="0x1028"
    ATTRS{subsystem_device}="0x01ad"
    ATTRS{class}="0x0c0300"
    ATTRS{irq}="22"
    ATTRS{local_cpus}="ffffffff"
    ATTRS{local_cpulist}="0-31"
    ATTRS{modalias}="pci:v00008086d000027C9sv00001028sd000001ADbc0Csc03i00"
    ATTRS{dma_mask_bits}="32"
    ATTRS{consistent_dma_mask_bits}="32"
    ATTRS{broken_parity_status}="0"
    ATTRS{msi_bus}=""

  looking at parent device '/devices/pci0000:00':
    KERNELS="pci0000:00"
    SUBSYSTEMS=""
    DRIVERS=""


-- 
 Dr. Ludovic Rousseau

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
@ 2010-09-09  9:36 ` Kay Sievers
  2010-09-09  9:57 ` Ludovic Rousseau
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2010-09-09  9:36 UTC (permalink / raw)
  To: linux-hotplug

On Thu, Sep 9, 2010 at 11:21, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> I am trying to write a udev configuration file to change the group
> ownership of the device if the device contains a CCID interface
> (bInterfaceClass = 11 or 0x0B).
>
> I would like to use something like:
> ATTR{bInterfaceClass}="0b", GROUP="pcscd"
> but that does not work.

That not possible. Udev can only match on properties of the device
ATTR or a parent device ATTRS.

The device node you want to set the group to is the usb_device, but
the match you want to do is on the usb_interface. At the moment the
usb_device event is handled, the usb_interface does not exist, so this
can never match. And from the usb_interface, which is a children and
comes after the usb_device, you can not change the parent device node.

Udev parses the usb descriptors and makes them available in a
property. That's the only way to access usb_interface properties from
the usb_device event.

Something like:
  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
should do it.

Kay

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
  2010-09-09  9:36 ` Kay Sievers
@ 2010-09-09  9:57 ` Ludovic Rousseau
  2010-09-09 20:49 ` David Zeuthen
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Ludovic Rousseau @ 2010-09-09  9:57 UTC (permalink / raw)
  To: linux-hotplug

2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
> On Thu, Sep 9, 2010 at 11:21, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> I am trying to write a udev configuration file to change the group
>> ownership of the device if the device contains a CCID interface
>> (bInterfaceClass = 11 or 0x0B).
>>
>> I would like to use something like:
>> ATTR{bInterfaceClass}="0b", GROUP="pcscd"
>> but that does not work.
>
> That not possible. Udev can only match on properties of the device
> ATTR or a parent device ATTRS.
>
> The device node you want to set the group to is the usb_device, but
> the match you want to do is on the usb_interface. At the moment the
> usb_device event is handled, the usb_interface does not exist, so this
> can never match. And from the usb_interface, which is a children and
> comes after the usb_device, you can not change the parent device node.
>
> Udev parses the usb descriptors and makes them available in a
> property. That's the only way to access usb_interface properties from
> the usb_device event.
>
> Something like:
>  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
> should do it.

Yes, it does work.

But I find the rule more obscure.

Since performance is not a critical point for me I think I will stay with:
ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"

Thanks

-- 
 Dr. Ludovic Rousseau

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
  2010-09-09  9:36 ` Kay Sievers
  2010-09-09  9:57 ` Ludovic Rousseau
@ 2010-09-09 20:49 ` David Zeuthen
  2010-09-10  9:49 ` Ludovic Rousseau
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: David Zeuthen @ 2010-09-09 20:49 UTC (permalink / raw)
  To: linux-hotplug

Hey,

On Thu, Sep 9, 2010 at 5:57 AM, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> > Something like:
> >  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
> > should do it.
>
> Yes, it does work.
>
> But I find the rule more obscure.
>
> Since performance is not a critical point for me I think I will stay with:
> ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"

Please don't. It's racy. In particular it will break if you have
daemons or apps listening for uevents and doing stuff when the device
node appears.

    David

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (2 preceding siblings ...)
  2010-09-09 20:49 ` David Zeuthen
@ 2010-09-10  9:49 ` Ludovic Rousseau
  2010-09-10 11:13 ` Marco d'Itri
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Ludovic Rousseau @ 2010-09-10  9:49 UTC (permalink / raw)
  To: linux-hotplug

2010/9/9 David Zeuthen <zeuthen@gmail.com>:
> Hey,
>
> On Thu, Sep 9, 2010 at 5:57 AM, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> > Something like:
>> >  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>> > should do it.
>>
>> Yes, it does work.
>>
>> But I find the rule more obscure.
>>
>> Since performance is not a critical point for me I think I will stay with:
>> ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
>
> Please don't. It's racy. In particular it will break if you have
> daemons or apps listening for uevents and doing stuff when the device
> node appears.

Would the race issue disappear if I use RUN= instead of RUN+=?
The chgrp command should not take to long to execute.

Yes, I also have a daemon listening for events. I am using libhal now
but plan to move to libudev "soon".

Thanks

-- 
 Dr. Ludovic Rousseau

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (3 preceding siblings ...)
  2010-09-10  9:49 ` Ludovic Rousseau
@ 2010-09-10 11:13 ` Marco d'Itri
  2010-09-10 11:24 ` Kay Sievers
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Marco d'Itri @ 2010-09-10 11:13 UTC (permalink / raw)
  To: linux-hotplug

On Sep 10, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:

> Would the race issue disappear if I use RUN= instead of RUN+=?
No. Please use GROUP, it works and is actually easier to understand what
it does.

-- 
ciao,
Marco

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (4 preceding siblings ...)
  2010-09-10 11:13 ` Marco d'Itri
@ 2010-09-10 11:24 ` Kay Sievers
  2010-09-10 15:14 ` Ludovic Rousseau
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2010-09-10 11:24 UTC (permalink / raw)
  To: linux-hotplug

On Fri, Sep 10, 2010 at 11:49, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> 2010/9/9 David Zeuthen <zeuthen@gmail.com>:
>> On Thu, Sep 9, 2010 at 5:57 AM, Ludovic Rousseau
>> <ludovic.rousseau@gmail.com> wrote:
>>> > Something like:
>>> >  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>>> > should do it.
>>>
>>> Yes, it does work.
>>>
>>> But I find the rule more obscure.
>>>
>>> Since performance is not a critical point for me I think I will stay with:
>>> ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
>>
>> Please don't. It's racy. In particular it will break if you have
>> daemons or apps listening for uevents and doing stuff when the device
>> node appears.
>
> Would the race issue disappear if I use RUN= instead of RUN+=?

No it wouldn't. It will break all other earlier rules. Device event
must never operate on other devices like their parent in this case.
It's just totally wrong to do anything like that. The next event for
the parent will restore the original mode again, without ever calling
your chgrp hack.

> The chgrp command should not take to long to execute.

It's not a matter of 'long'. A race is a race, and must be avoided.

Kay

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (5 preceding siblings ...)
  2010-09-10 11:24 ` Kay Sievers
@ 2010-09-10 15:14 ` Ludovic Rousseau
  2010-09-13  9:34 ` Kay Sievers
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Ludovic Rousseau @ 2010-09-10 15:14 UTC (permalink / raw)
  To: linux-hotplug

2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
> On Thu, Sep 9, 2010 at 11:21, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> I am trying to write a udev configuration file to change the group
>> ownership of the device if the device contains a CCID interface
>> (bInterfaceClass = 11 or 0x0B).
>>
>> I would like to use something like:
>> ATTR{bInterfaceClass}="0b", GROUP="pcscd"
>> but that does not work.
>
> That not possible. Udev can only match on properties of the device
> ATTR or a parent device ATTRS.
>
> The device node you want to set the group to is the usb_device, but
> the match you want to do is on the usb_interface. At the moment the
> usb_device event is handled, the usb_interface does not exist, so this
> can never match. And from the usb_interface, which is a children and
> comes after the usb_device, you can not change the parent device node.
>
> Udev parses the usb descriptors and makes them available in a
> property. That's the only way to access usb_interface properties from
> the usb_device event.
>
> Something like:
>  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
> should do it.

It works but is not what I need.
- Why do you use = instead of = for ENV{ID_USB_INTERFACES}? I want to
check the value of ID_USB_INTERFACES, not set it.
- Why use "*" in "*:0b0000:*"?

Instead I used a =
SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP="pcscd"
or
SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}=":0b0000:", GROUP="pcscd"
But it does not work :-(

So I still have no working solution (except using RUN+=)

Thanks

-- 
 Dr. Ludovic Rousseau

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (6 preceding siblings ...)
  2010-09-10 15:14 ` Ludovic Rousseau
@ 2010-09-13  9:34 ` Kay Sievers
  2010-09-13 12:42 ` Ludovic Rousseau
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2010-09-13  9:34 UTC (permalink / raw)
  To: linux-hotplug

On Fri, Sep 10, 2010 at 17:14, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> 2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:

>> Udev parses the usb descriptors and makes them available in a
>> property. That's the only way to access usb_interface properties from
>> the usb_device event.
>>
>> Something like:
>>  SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>> should do it.
>
> It works but is not what I need.
> - Why do you use = instead of = for ENV{ID_USB_INTERFACES}? I want to
> check the value of ID_USB_INTERFACES, not set it.
> - Why use "*" in "*:0b0000:*"?
>
> Instead I used a =
> SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP="pcscd"
> or
> SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}=":0b0000:", GROUP="pcscd"
> But it does not work :-(

Sure, it should be =. Make sure that your rule file sorts after
50-udev-default-rules, which calls usb_id, and sets this property.

Kay

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (7 preceding siblings ...)
  2010-09-13  9:34 ` Kay Sievers
@ 2010-09-13 12:42 ` Ludovic Rousseau
  2010-09-13 12:48 ` Marco d'Itri
  2010-09-13 12:56 ` Ludovic Rousseau
  10 siblings, 0 replies; 12+ messages in thread
From: Ludovic Rousseau @ 2010-09-13 12:42 UTC (permalink / raw)
  To: linux-hotplug

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

2010/9/13 Kay Sievers <kay.sievers@vrfy.org>:
> On Fri, Sep 10, 2010 at 17:14, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> 2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
>
>>> Udev parses the usb descriptors and makes them available in a
>>> property. That's the only way to access usb_interface properties from
>>> the usb_device event.
>>>
>>> Something like:
>>>  SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>>> should do it.
>>
>> It works but is not what I need.
>> - Why do you use = instead of == for ENV{ID_USB_INTERFACES}? I want to
>> check the value of ID_USB_INTERFACES, not set it.
>> - Why use "*" in "*:0b0000:*"?
>>
>> Instead I used a ==
>> SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}=="*:0b0000:*", GROUP="pcscd"
>> or
>> SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}==":0b0000:", GROUP="pcscd"
>> But it does not work :-(
>
> Sure, it should be ==. Make sure that your rule file sorts after
> 50-udev-default-rules, which calls usb_id, and sets this property.

My 50-udev-default-rules files does not use usb_id (file attached).
But other files in /lib/udev/rules.d/ do. The first one is
60-persistent-alsa.rules

I renamed my rule file from 50_pcscd_ccid.rules to 51_pcscd_ccid.rules
to be sorted after 50-udev-default-rules but the rule still do not
work.

I can see the "ID_USB_INTERFACES=:0b0000:" line in "udevadm monitor
--env --kernel udev" output but that is for an interface, not for the
device itself.
Maybe that is because my 50-udev-default-rules file is not using usb_id?


What is the use of GROUP="" supposed to do on an interface?
Is it possible to propagate the group change on the parent device node?

Thanks

-- 
 Dr. Ludovic Rousseau

[-- Attachment #2: 50-udev-default.rules --]
[-- Type: application/octet-stream, Size: 3548 bytes --]

SUBSYSTEM=="block",				SYMLINK{unique}+="block/%M:%m"
SUBSYSTEM!="block",				SYMLINK{unique}+="char/%M:%m"

# import the properties of optical drives
ACTION!="remove", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", \
	KERNEL=="sr[0-9]*|hd[a-z]|pcd[0-9]|xvd*", \
	IMPORT{program}="cdrom_id --export $tempnode"

# SCSI devices
SUBSYSTEMS=="scsi", KERNEL=="sr[0-9]*",		SYMLINK+="scd%n"
SUBSYSTEM=="bsg",				NAME="bsg/%k"

# workaround for kernels < 2.6.30
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", WAIT_FOR_SYSFS="descriptors"

# USB devices
SUBSYSTEMS=="usb", KERNEL=="auer[0-9]*",	NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="cpad[0-9]*",	NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="dabusb[0-9]*",	NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="hiddev[0-9]*",	NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="legousbtower[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="lp[0-9]*",		NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="iowarrior[0-9]*",	NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
	ATTRS{product}=="[Hh]andspring*Treo*|[Hh]andspring*Visor*|[Pp]alm*Handheld*", \
						SYMLINK+="pilot"

# usbfs-like devices
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",	NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}"

# serial devices
KERNEL=="capi",			NAME="capi20",
KERNEL=="capi[0-9]*",		NAME="capi/%n"

# video devices
KERNEL=="dvb*",	ENV{DVB_ADAPTER_NUM}=="?*",	NAME="dvb/adapter$env{DVB_ADAPTER_NUM}/$env{DVB_DEVICE_TYPE}$env{DVB_DEVICE_NUM}"
# workaround for kernels < 2.6.29
KERNEL=="dvb*",	ENV{DVB_ADAPTER_NUM}=="", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}", ACTION!="remove", \
				NAME="$result"
KERNEL=="card[0-9]*",		NAME="dri/%k"

# virtio serial / console ports
KERNEL=="vport*", ATTR{name}=="?*", SYMLINK+="virtio-ports/$attr{name}"

# misc devices
KERNEL=="hw_random",		NAME="hwrng"
KERNEL=="tun",			NAME="net/%k"
KERNEL=="evtchn",		NAME="xen/%k"
SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos",		SYMLINK+="rtc"

KERNEL=="rawctl",		NAME="raw/rawctl"
KERNEL=="cdemu[0-9]*",		NAME="cdemu/%n"
KERNEL=="pktcdvd[0-9]*",	NAME="pktcdvd/%n"
KERNEL=="pktcdvd",		NAME="pktcdvd/control"

KERNEL=="cpu[0-9]*",		NAME="cpu/%n/cpuid"
KERNEL=="msr[0-9]*",		NAME="cpu/%n/msr"
KERNEL=="microcode",		NAME="cpu/microcode"

KERNEL=="umad*",		NAME="infiniband/%k"
KERNEL=="issm*",		NAME="infiniband/%k"
KERNEL=="uverbs*",		NAME="infiniband/%k"
KERNEL=="ucm*",			NAME="infiniband/%k"
KERNEL=="uat",			NAME="infiniband/%k"
KERNEL=="ucma",			NAME="infiniband/%k"
KERNEL=="rdma_cm",		NAME="infiniband/%k"

# ALSA devices
KERNEL=="controlC[0-9]*",	NAME="snd/%k"
KERNEL=="hwC[D0-9]*",		NAME="snd/%k"
KERNEL=="pcmC[D0-9cp]*",	NAME="snd/%k"
KERNEL=="midiC[D0-9]*",		NAME="snd/%k"
KERNEL=="timer",		NAME="snd/%k"
KERNEL=="seq",			NAME="snd/%k"

KERNEL=="snd", SUBSYSTEM=="module", ACTION=="add", \
	RUN+="/bin/ln -sf /proc/asound/oss/sndstat $root/sndstat"


# ieee1394 devices
KERNEL=="dv1394*",		NAME="dv1394/%n"
KERNEL=="video1394*",		NAME="video1394/%n"

# input devices
KERNEL=="mice",			NAME="input/%k"
KERNEL=="mouse[0-9]*",		NAME="input/%k"
KERNEL=="event[0-9]*",		NAME="input/%k"
KERNEL=="js[0-9]*",		NAME="input/%k"
KERNEL=="ts[0-9]*",		NAME="input/%k"
KERNEL=="uinput",		NAME="input/%k"

# Zaptel
KERNEL=="zapctl",		NAME="zap/ctl"
KERNEL=="zapchannel",		NAME="zap/channel"
KERNEL=="zappseudo",		NAME="zap/pseudo"
KERNEL=="zaptimer",		NAME="zap/timer"
KERNEL=="transcode",		NAME="zap/transcode"
KERNEL=="zap[0-9]*",		NAME="zap/%n"

# AOE character devices
SUBSYSTEM=="aoe",		NAME="etherd/%k"

KERNEL=="device-mapper",	NAME="mapper/control"


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (8 preceding siblings ...)
  2010-09-13 12:42 ` Ludovic Rousseau
@ 2010-09-13 12:48 ` Marco d'Itri
  2010-09-13 12:56 ` Ludovic Rousseau
  10 siblings, 0 replies; 12+ messages in thread
From: Marco d'Itri @ 2010-09-13 12:48 UTC (permalink / raw)
  To: linux-hotplug

On Sep 13, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:

> My 50-udev-default-rules files does not use usb_id (file attached).
> But other files in /lib/udev/rules.d/ do. The first one is
> 60-persistent-alsa.rules
Debian applies the permissions at 91, so your file needs to sort after
91-permissions.rules. This is documented in README.Debian.

Kay, if rules files can depend of usb_id being ran at a certain point
instead of running it themselves like the standard rules files currently
do then you should say so...

-- 
ciao,
Marco

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Use GROUP= in a rule matching an interface of the device?
  2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
                   ` (9 preceding siblings ...)
  2010-09-13 12:48 ` Marco d'Itri
@ 2010-09-13 12:56 ` Ludovic Rousseau
  10 siblings, 0 replies; 12+ messages in thread
From: Ludovic Rousseau @ 2010-09-13 12:56 UTC (permalink / raw)
  To: linux-hotplug

2010/9/13 Marco d'Itri <md@linux.it>:
> On Sep 13, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:
>
>> My 50-udev-default-rules files does not use usb_id (file attached).
>> But other files in /lib/udev/rules.d/ do. The first one is
>> 60-persistent-alsa.rules
> Debian applies the permissions at 91, so your file needs to sort after
> 91-permissions.rules. This is documented in README.Debian.

Renamed the rule file to 92_pcscd_ccid.rules.
And it works! :-)

Thanks to all,

-- 
 Dr. Ludovic Rousseau

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2010-09-13 12:56 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-09  9:21 Use GROUP= in a rule matching an interface of the device? Ludovic Rousseau
2010-09-09  9:36 ` Kay Sievers
2010-09-09  9:57 ` Ludovic Rousseau
2010-09-09 20:49 ` David Zeuthen
2010-09-10  9:49 ` Ludovic Rousseau
2010-09-10 11:13 ` Marco d'Itri
2010-09-10 11:24 ` Kay Sievers
2010-09-10 15:14 ` Ludovic Rousseau
2010-09-13  9:34 ` Kay Sievers
2010-09-13 12:42 ` Ludovic Rousseau
2010-09-13 12:48 ` Marco d'Itri
2010-09-13 12:56 ` Ludovic Rousseau

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.