From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric S. Raymond" Date: Fri, 11 Mar 2005 15:40:46 +0000 Subject: Re: New hotplug interface is not working right for me Message-Id: <20050311154046.GA19837@thyrsus.com> List-Id: References: <20050311060405.GA16141@thyrsus.com> In-Reply-To: <20050311060405.GA16141@thyrsus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Kay Sievers : > 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? > 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. 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? -- Eric S. Raymond ------------------------------------------------------- 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_id396&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