From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Sat, 01 Jun 2002 00:21:52 +0000 Subject: Re: Which node has the device been bound to? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sat, Jun 01, 2002 at 02:05:25AM +0200, Oliver Neukum wrote: > > > > In case of one iPAQ, we can find the relevant log entry by grepping the > > > LAST matched line. But if two iPAQs are attached nearly at the same > > > time, the last matched line may not be the relevant entry because > > > context switching may happen between two agent scripts. > > > > > > Do you have any method that can solve it? > > > > Right now, no, sorry. > > > > In the 2.5 tree, the usbserial driver creates a > > /proc/tty/driver/usbserial file that allows you to see all of the > > different usbserial devices currently connected to the system, but it > > doesn't really help you in determining which iPAQ is which. > > Do you think that it's wise to introduce yet another driver > specific file ? Not really, but it follows the way _all_ other tty drivers do it :) > > The driverfs changes that are slowly going into the tree might > > eventually help you out. Check out the changes that will be in 2.5.20 > > for the usb tree (they look much like the pci tree in 2.5.19 if you want > > to compare that right now.) > > > > And how would you be able to determine uniquely each iPAQ anyway? Do > > they have unique USB serial numbers or would you want to determine the > > device based on the physical USB port it is plugged into on the host? > > You might not like it, but I still think that a standard ioctl() would > be the best way to export such information. Could you enlighten > me on how you want to make sure that the information you act on > is guaranteed to be current, if you do not base the mechanism > on the opened device ? Have you seen the way driverfs shows the usb and pci topology? And yes, you might be acting on old data. But if you have an ioctl() what would it return? A pointer to the topology location which might have just changed? I don't see how an ioctl() can solve this problem any different from the way driverfs is going about it. But I could be missing something. :) thanks, greg k-h _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ 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