ENV variable scope question

ENV variable scope question

[Aras Vaichas]

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"

I had hoped to be able to match this LCDD_DEVICE variable when the
kernel name appeared in the remove event. So I tried:

ACTION="remove", ENV{LCDD_DEVICE}="%k", RUN+="... remove the driver ..."

But this rule never triggered.

I put in a debug line, and disconnected the device:

ACTION="remove", RUN+="/bin/sh -c 'logger B %k = $env{LCDD_DEVICE}'"

Jan  1 00:41:21 user.notice root: B usbdev1.23_ep81 Jan  1 00:41:21 user.notice root: B usbdev1.23_ep02 Jan  1 00:41:21 user.notice root: B usbdev1.23_ep00 = usbdev1.23_ep00
<--- !!!
Jan  1 00:41:21 user.notice root: B ttyUSB1 Jan  1 00:41:21 user.notice root: B ttyUSB1 Jan  1 00:41:21 user.notice root: B 1-1:1.0 Jan  1 00:41:21 user.notice root: B 1-1 
So there is a situation where %k  was equal to LCDD_DEVICE, but
regardless the rule didn't trigger. Did I get the syntax wrong?

Also, it appears that the scope of the environment variable LCDD_DEVICE
only occurs when the actual device has caused the uevent. OK.

So should I make my remove rule like this?

ACTION="remove", ENV{LCDD_DEVICE}!="", RUN+="... remove the driver ..."

Aras

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: ENV variable scope question

[Aras Vaichas]

Sujit Karataparambil wrote:
>> ACTION="remove", ENV{LCDD_DEVICE}="%k", RUN+="... remove the >driver ..."
>>     
>
> SUBSYSTEM="usb_endpoint", ACTION="remove",
> RUN+="/etc/udev/dev.d/script/umount.dev"
>   
No, that won't work because it will trigger for *every* USB unplug
event.  Anyway,  that doesn't answer the main question of the thread.

> Some thing that might be helpfull is.
> udevcontrol reload_rules
>   
No, I don't need to do that because udev will automatically reload the
rules via inotify.

Also, that command is obsolete. The new version is this:

# udevadm control --reload-rules

Aras

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

FW:Re: ENV variable scope question

[Sujit Karataparambil]

On 8/21/08, Sujit Karataparambil <sjt.kar@gmail.com> wrote:
> > ACTION="remove", ENV{LCDD_DEVICE}="%k", RUN+="... remove the >driver ..."
>
> SUBSYSTEM="usb_endpoint", ACTION="remove",
> RUN+="/etc/udev/dev.d/script/umount.dev"
>
> Some thing that might be helpfull is.
> udevcontrol reload_rules
>
> --
> --linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+)
>


-- 
--linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+)

Re: ENV variable scope question

[Aras Vaichas]

Sujit Karataparambil wrote:
>> No, that won't work because it will trigger for *every* USB unplug
>> event.  Anyway,  that doesn't answer the main question of the thread.
>>     
>
> Sorry This is what i meant.
>
> ACTION="add",SUBSYSTEM="usb_endpoint",ATTR{device/manufacturer}="Crystalfontz",RUN+="/usr/bin/myprogram
> up lcdd"

Sujit, that is exactly what I wrote in the original email.

Please read my emails carefully, you don't understand what it is that I
am asking.

Aras



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: FW:Re: ENV variable scope question

[Kay Sievers]

On Thu, Aug 21, 2008 at 07:21, Sujit Karataparambil <sjt.kar@gmail.com> wrote:
> On 8/21/08, Sujit Karataparambil <sjt.kar@gmail.com> wrote:
>> > ACTION="remove", ENV{LCDD_DEVICE}="%k", RUN+="... remove the >driver ..."
>>
>> SUBSYSTEM="usb_endpoint", ACTION="remove",
>> RUN+="/etc/udev/dev.d/script/umount.dev"
>>
>> Some thing that might be helpfull is.
>> udevcontrol reload_rules

No, that is almost never needed. Udevd does that just fine by inotify watches.

Kay

Re: ENV variable scope question

[Kay Sievers]

On Thu, Aug 21, 2008 at 03:37, Aras Vaichas <arasv@magtech.com.au> 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.

> I had hoped to be able to match this LCDD_DEVICE variable when the
> kernel name appeared in the remove event. So I tried:
>
> ACTION="remove", ENV{LCDD_DEVICE}="%k", RUN+="... remove the driver ..."
>
> But this rule never triggered.
>
> I put in a debug line, and disconnected the device:
>
> ACTION="remove", RUN+="/bin/sh -c 'logger B %k = $env{LCDD_DEVICE}'"
>
> Jan  1 00:41:21 user.notice root: B usbdev1.23_ep81 > Jan  1 00:41:21 user.notice root: B usbdev1.23_ep02 > Jan  1 00:41:21 user.notice root: B usbdev1.23_ep00 = usbdev1.23_ep00
> <--- !!!
> Jan  1 00:41:21 user.notice root: B ttyUSB1 > Jan  1 00:41:21 user.notice root: B ttyUSB1 > Jan  1 00:41:21 user.notice root: B 1-1:1.0 > Jan  1 00:41:21 user.notice root: B 1-1 >
> So there is a situation where %k  was equal to LCDD_DEVICE, but
> regardless the rule didn't trigger. Did I get the syntax wrong?
>
> Also, it appears that the scope of the environment variable LCDD_DEVICE
> only occurs when the actual device has caused the uevent. OK.
>
> So should I make my remove rule like this?
>
> 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"

Try setting:
  ENV{REMOVE_CMD}="/bin/something"
with the "add" rule, it should be called by udev itself on "remove".

Kay

Re: ENV variable scope question

[Aras Vaichas]

Kay Sievers wrote:
> On Thu, Aug 21, 2008 at 03:37, Aras Vaichas <arasv@magtech.com.au> 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.

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

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"

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

>> 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?

Aras

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: ENV variable scope question

[Kay Sievers]

On Thu, Aug 21, 2008 at 09:17, Aras Vaichas <arasv@magtech.com.au> wrote:
> Kay Sievers wrote:
>> On Thu, Aug 21, 2008 at 03:37, Aras Vaichas <arasv@magtech.com.au> 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

Re: ENV variable scope question

[Aras Vaichas]

>>> On Thu, Aug 21, 2008 at 03:37, Aras Vaichas <arasv@magtech.com.au> wrote:
>>>> Hi, I'm looking to unload a userspace driver when a particular
>>>> device is removed.

Here are my (hopefully) final rules.  I have to load/unload on the
usb_device because the ttyUSB[0-9]
device doesn't get disconnected if an application still has the dev file
open.

ACTION="add", ENV{DEVTYPE}="usb_device",
ATTRS{manufacturer}="Crystalfontz", ENV{REMOVE_CMD}="/usr/bin/sv down
lcdd", RUN+="/usr/bin/sv up lcdd"
ACTION="add", KERNEL="ttyUSB[0-9]",
ATTRS{manufacturer}="Crystalfontz", SYMLINK+="lcd"

These rules will:
* load the LCDproc daemon when a supported USB LCD device is plugged in
* create a symbolic link so that the the lcdd configuration file will
always point to the correct ttyUSB*
* facilitate the shutdown of the demon which releases the ttyUSB* device
and frees it for further use

It will fail though if two of the same device are plugged in but that
would be an unusual situation for my embedded product and I can live
with that.


> 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

udevadm info --query=all --name=ttyUSB0 --attribute-walk

This is also very helpful, and would have saved me some time, but I
didn't know that this is what I really wanted all along. :P

I think my next rule set will be a lot easier and faster now that I
better understand what it is that I am supposed to be looking for.

Thanks for all the help and tips.

Aras

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________