Re: New hotplug interface is not working right for me

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, 2005-03-11 at 10:40 -0500, Eric S. Raymond wrote:
> Kay Sievers <kay.sievers@vrfy.org>:
> > No, not today, not with the current version. We are just thought about
> > adding rule based program execution, cause it is similar to all the
> > match logic to name a device and it would be more elegant than the
> > current directory searching.
> 
> Agreed.  Mark me in favor of the feature, though not strongly attached to
> it if anyone comes up with a better architectural approach.
>  
> > > # The Prolific Technology 2303 (commonly in tandem with SiRF chips)
> > > BUS="usb" ACTION="add" SYSFS{vendor}="067b" SYSFS{product}="2303" \
> > > 		NAME="gps%e" \
> > > 		HOTPLUG="/usr/bin/gps-probe"
> > > # FTDI 8U232AM
> > > BUS="usb" ACTION="add" SYSFS{vendor}="0403" SYSFS{product}="6001" \
> > > 		NAME="gps%e" \
> > > 		HOTPLUG="/usr/bin/gps-probe"
> > > # Cypress M8/CY7C64013 (DeLorme uses these)
> > > BUS="usb" ACTION="add" SYSFS{vendor}="1163" SYSFS{product}="0100" \
> > > 		NAME="gps%e" \
> > > 		HOTPLUG="/usr/bin/gps-probe"
> > > 
> > > 1. Am I correct that when triggered, these would create a device called
> > >    /dev/gpsN for some enumerated N?
> > 
> > Yes, this would be correct, if we decide to support the HOTPLUG key. For
> > now you need to put a script in /etc/dev.d/* that needs to check if a
> > DEVNAME=gps* is in the environment.
> 
> I think I see what you're getting at here, but would you either be explicit
> about the activation rule for /etc/dev.d/ scripts or point me at documentation
> of same?

After node creation/removal udev executes the following scripts:
  /etc/dev.d/$DEVNAME/*.dev
  /etc/dev.d/$SUBSYSTEM/*.dev
  /etc/dev.d/default/*.dev

You may place your executable script or a symlink to it as:
  /etc/dev.d/tty/gps.dev

and check for ACTION and DEVNAME values to sort out wrong devices and
match your action.

> > And the enumeration %e is an ugly thing in a world where devices can
> > come and go at any time. The result is unpredictable if you don't
> > connect and probe in the same order every time and under all situations
> > like suspend/resume, reboot, later plug-in.
> > If possible, these simple kind of enumerations should be avoided and the
> > names should depend on a unique attribute like a device serial number or
> > similar. Or the physical location can possibly be included in the device
> > node name if there is no better attribute.
> 
> Gotcha.   For my application, 
> 
> (a) Name uniqueness is valuable but name persistence is not necessary or even
> particularly useful -- so %e would be functionally OK.  
> 
> (b) I fundamentally don't care what the uniquifier is.
>
> > > 2. What is the lifetime of that device?  Under what circumstances is it
> > >    removed?
> > 
> > The device will stay there as long as the kernel represents the device.
> > If the kernel discovers a USB-disconnect the node will be removed and a
> > newly connected device will get the lowest free %e number in the node
> > name.
> 
> OK, that's exactly the answer I expected, even to the rule for %e allocation.  
> Good to have it confirmed.
> 
> One more question: what happens if I leave out the ACTION clause?  Ideally,
> I'd like the device node to still be created on add and deleted on remove,
> but with the script waking up on both actions.

That's the default. The scripts are invoked on "add" and "remove". The
DEVNAME value for the "remove" event comes from the udev database, not
from a rule. The ACTION key will only be needed if we do hotplug script
execution by rule.

> The udev documentation looks pretty good, but it could stand to be a touch more
> explicit in spots.  If I generate patches to fix this, where should I send 
> them?

That would be nice. To that list is fine, here happens all the udev
discussion.

Thanks,
Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel