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. > 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. > 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 suppose one can ask about the resources allocated for a file that has > been opened, and someone else deletes file. The application still sees > the file, but the rest of the world does not. a new file, with same name > can be created which wont affect the deleted, but still present file. > Once the deleted file is closed, those resources will be returned to > their respective pools. Unfortunately, tty device nodes are treated differently by the kernel from regular file nodes. I don't know why that is or what would be needed to change it; it might have to do with the inner workings of the tty subsystem -- with which I am completely unfamiliar. There are others on this mailing list who know more about it. > Garmin_GPS, the device handler for the hockey puck GPS device, knows > that the newly plugged in USB device is inder its wings. Does garmin_gps > know that the device has disconnected? It certainly knows when the USB > device gets connected. Yes, the device driver is notified about both connect and disconnect events. > I suppose we can play mix & match for some time with when and how USB > devices get connected and assigned /dev/ names. But if you cannot get > garmin_gps to reconnect to ttyUSB0 when the device is unplugged ( but > not closed) then maybe the special dev should be erased, and the > internal names erased. I'm not familiar enough with either the tty subsystem or with the way the USB subsystem interacts with it to provide much help. What happens if you plug in the GPS device, unplug it (without running any programs), and then plug it back in again? Does it return as ttyUSB0, or does it become ttyUSB1 in spite of the fact that there is no more ttyUSB0? Different subsystems are inconsistent in the way they number devices. For example, the SCSI subsystem numbers host adapters in increasing order, always. The next host adapter gets the next number, even if some earlier numbers have become available again. By contrast, SCSI disks are assigned the first available disk letter, so if a disk is removed and then reconnected its letter will be reused. Alan Stern ------------------------------------------------------------------------- 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
