All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aras Vaichas <arasv@magtech.com.au>
To: linux-hotplug@vger.kernel.org
Subject: Re: ENV variable scope question
Date: Thu, 21 Aug 2008 07:17:20 +0000	[thread overview]
Message-ID: <48AD1680.8010705@magtech.com.au> (raw)
In-Reply-To: <48ACC6DD.4070705@magtech.com.au>

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 
______________________________________________________________________

  parent reply	other threads:[~2008-08-21  7:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-21  1:37 ENV variable scope question Aras Vaichas
2008-08-21  5:30 ` Aras Vaichas
2008-08-21  5:33 ` FW:Re: " Sujit Karataparambil
2008-08-21  5:47 ` Aras Vaichas
2008-08-21  6:31 ` FW:Re: " Kay Sievers
2008-08-21  6:45 ` Kay Sievers
2008-08-21  7:17 ` Aras Vaichas [this message]
2008-08-21  7:57 ` Kay Sievers
2008-08-22  3:44 ` Aras Vaichas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48AD1680.8010705@magtech.com.au \
    --to=arasv@magtech.com.au \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.