Re: [linux-usb-devel] file_storage gadget requires a sync...
Alan Stern wrote: Yes, of course we always write device drivers so that they will fail in unexpected ways unless the user does something unintuitive and undocumented. :-) Ya, we all knew that. Just so long as you understand that we users all read the hardware docs from cover to cover, looking for all those undocumented features just so we can justify the errant driver report. :} - 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
[linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Robert Hancock wrote: It's because you haven't done anything to handle the error which is still persisting. Likely the only thing sane you can do in this case is close the fd and try to reopen it later. This seems to be true, but not for what you might think. It appears that if u plug the USB/serial device back into the usb-hub, the code creates a /dev/ttyUSB1 ( if you have not yet closed the disconnected /dev/ttyUSB0. ) When you do close /dev/ttyUSB0, then the device is erased from the /dev directory. Now /dev/ttyUSB1 is the device. And /dev/ttyUSB0 disappeared. This does not seem proper. As now the program has no idea or capability to re-open the GPS device. I have been informed that this was an approved kernel feature. Is this suppose to happen? Or was it an unintended consequence? NOTE: this was a continuing discussion on what select() should be returning if a USB device is physically pulled from its socket. Then, of course, what happens when you plug the device back in. I received no reply to what (should) happen when the device is plugged back in, but the FD has not yet been closed. - 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
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
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. 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. 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 ). 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. 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. 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. - 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
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
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
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Pete Zaitcev wrote:
BTW, here's the recipy I use for my GPS (I use it as timing source,
so ntpd has to be able to find it in fixed place):
[EMAIL PROTECTED] ~]$ cat /etc/udev/rules.d/70-gps.rules
KERNEL==ttyACM*, SYSFS{idVendor}==0b20 SYSFS{idProduct}==0406,
SYMLINK+=gps0
[EMAIL PROTECTED] ~]$
How much of the precise do u believe, in the GPS time, that is presented
to you?
When I get a datum, i never know how long the time info has been sitting
inside the unit. And with the street trips gps-360 receiver, u can
actually ( visually ) notice that some time reports are off.
-
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
