Re: ENV variable scope question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 21, 2008 at 09:17, Aras Vaichas <arasv@xxxxxxxxxxxxxx> wrote:
> Kay Sievers wrote:
>> On Thu, Aug 21, 2008 at 03:37, Aras Vaichas <arasv@xxxxxxxxxxxxxx> wrote:
>>
>>> Hi, I'm looking to unload a userspace driver when a particular device is
>>> removed.
>>>
>>> My load rule is this:
>>>
>>> ACTION=="add",SUBSYSTEM=="usb_endpoint",ATTR{device/manufacturer}=="Crystalfontz",
>>> RUN+="/usr/bin/sv up lcdd"
>>>
>>> Now the problem was that when I disconnect the device there is no longer
>>> a "device/manufacturer" file, so I added an environment variable
>>> LCDD_DEVICE to the rule:
>>>
>>> ACTION=="add",SUBSYSTEM=="usb_endpoint",ATTR{device/manufacturer}=="Crystalfontz",
>>> ENV{LCDD_DEVICE}="%k", RUN+="/usr/bin/sv up lcdd"
>>>
>>
>> Why do you match against the endpoint? These devices do not do anything.
>>
>> You should also never use the "device" link, it's deprecated and udev
>> should print a warning to the logs.
>>
> Well the problem was that the device uses a common USB-to-serial chip
> (FTDI) and they didn't change the VID/PID numbers for their product.
> This means that I could plug in a USB-to-serial cable which uses the
> same chip and I wouldn't know the difference if I just looked at the
> VID/PID numbers.
>
> So to avoid any ambiguity I wanted to load the application only when the
> exact device was plugged in. The manufacturer field seemed to be the
> best discriminator.

But "manufacturer" _is_ a property of the "usb_device", not the
interface, or the endpoint.

> Is there a better way to distinguish between the same USB-serial chip
> that is used in different devices?

Sounds fine, if they use the "manufacturer" field.

> For example, I want to add a symlink for ttyUSB[0-9] only when the
> Manufucturer is Crystalfontz, so I do:
>
> ACTION=="add", KERNEL=="ttyUSB[0-9]",
> ATTR{../../../../manufacturer}=="Crystalfontz", SYMLINK+="lcd"

".." must not be used anywhere, the kernel is free to change the
hierarchy anytime. Udev should also print a warning. Just use ATTRS{},
it will search up the chain of parents and try to find a
"manufacturer" attribute.

> Is this safer? Should I use this same method for loading the driver?

No.

>>> ACTION=="remove", ENV{LCDD_DEVICE}!="", RUN+="... remove the driver ..."
>>>
>> By matching on the endpoint, you get several events which will all
>> trigger your script. Try using the USB-device only, by adding:
>>   ENV{DEVTYPE}=="usb_device"
>>
> Ok.
>
>> Try setting:
>>   ENV{REMOVE_CMD}="/bin/something"
>> with the "add" rule, it should be called by udev itself on "remove".
>>
> Good idea, use a standard naming scheme.
>
> So, does udev maintain a separate environment space for each /dev point
> that it processes?

It's per device, stored in the udev database. You can look at it with:
  /sbin/udevadm info --query=all --name=ttyUSB0
or watch it while add/remove a device:
  /sbin/udevadm monitor --udev --env

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

[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     [X.org]     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux