Alan Stern wrote: > On Sun, 3 Jun 2007, Uncle George wrote: > >> Alan Stern wrote: >> >>> Another way of thinking about it: Suppose an existing device entry was >>> not removed (or least made inaccessible) when you unplugged the device >>> -- the idea being that the existing entry could be reused if you >>> plugged the device back in. Then if you never did plug it back in, the >>> old entry would hang around indefinitely, using up resources for no >>> good reason. >>> >>> Alan Stern >> How about thinking this way: >> Got a GPS hockey puck plugged into a hub. the ttyUSB0 is created, and >> the user program sees that there is a ttyUSB0. >> Application opens ttyUSB0. Application processes data from ttyUSB0. >> Everybody happy, till someone yanks the USB cord so that the connection >> is broken. >> >> Kernel sees I/O error. Application program sees I/O error. >> Application program has no idea what happened. 5 seconds later tries to >> reestablish communications with device ( still gets I/O error ). >> /dev/ttyUSB0 still alive because the application still has it opened. >> >> Now User realises that the cable was unplugged. plugs it back in. Now >> there is a ttyUSB1, and an effectively a >> dead ttyUSB0. > > Actually ttyUSB0 has been dead ever since the cable was unplugged. Not sure what you mean by that. The device may not be dead, as it may be plugged into a powered usb hub. > >> Even though the user has plugged in the USB device, the application >> still reports error. Application does not know or understand that the >> USB device is now connected to ttyUSB1. > > Nor does the kernel. All it knows is that _some_ device is now > connected to ttyUSB1. There's no way to tell that this device is in > fact the same as the one which used to be connected to ttyUSB0. Well, all it knows is that some device has connected. The kern then calls the various drivers to see is the usb device belongs to it. Garmin_gps claims device. the driver module. garmin_gps for example, then has to deceide what to do. garmin_gps knows that now a device with an identical signature is back. Is it the same as what was plugged? I dont think that has much relevance. > >> After some arbitrary while, application thinks the device is dead ( or >> user has told application so, presuming that user has any idea as to >> what happened ). Application closes FD channel. Now /dev/ttyUSB0 disappears. >> User says to application - go open ttyUSB0. Its plugged back in. its the >> only USB device. ttyUSB0 is not to be found ( under this scenario ). > > Why did the user tell the application to go open ttyUSB0? He should > have told it to go open ttyUSB1. Or better yet, to go look for any > available ttyUSB* device and present a list of possible choices if > there's more than one. > > Think about it. What would happen if you had 2 GPS devices and plugged > them both in simultaneously? One would become ttyUSB0 and the other > would become ttyUSB1. Now suppose you unplugged the ttyUSB0 device. > How would you start up the application at this point? I think its more interesting on how the user would determine which ttyUSB? is driving which device. But back to your example. The user knows that there are 2 usb devices, and 2 ttyUSB? got created. Application, at startup knows that there are 2 ttyUSB's, as the application, at startup scanned /dev/ Now, all of a sudden, there are 3 ttyUSB's . I was thinking of changing the udev .conf file to recognize the garmin_gps devices as /dev/GPS%d . But I perceive that there will be the same issues. > >> I suppose one can ask about the resources allocated for a file that has
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
