Greg KH <[EMAIL PROTECTED]> writes:
> On Wed, Jul 12, 2006 at 03:42:14PM +0400, Sergei Organov wrote:
>> Suppose I have a usb-serial device managed, say, by the airprime
>> driver. When I connect it, it is attached to the /dev/ttyUSB0, then,
>> every disconnect/connect results in detaching from /dev/ttyUSB0 and
>> attaching back to /dev/ttyUSB0 *unless* there is an application that
>> keeps an opened fd got from open("/dev/ttyUSB0") while
>> disconnect/connect happens, in which case the device is attached to
>> /dev/ttyUSB1.
>
> Yes, that's true.
>
>> It's OK that the application keeping the fd open can do nothing sensible
>> with it after corresponding device has been disconnected (and connected
>> back), but can the /dev/ttyUSB0 itself be freed for allocation at
>> disconnect time? Is there something fundamental that prevents it or
>> makes it undesirable?
>
> The application will get a signal that the device has "hung up" which
> usually causes it to automatically close the file handle, which is about
> the best that the kernel can provide.Well, simple test shows that an application just sees an EOF condition, i.e., read() returns 0 when device is disconnected. I don't think interactive terminal applications that are designed to work with RS232 ports are expecting either EOF or device to suddenly disappear, so they may well just ignore zero return code from read()/write(), at least neither my own application nor minicom closes the file on device disconnect. Another issue is: even if application reacts to the return code from read()/write() by closing the file handle, it could happen either before or after the kernel re-attaches the device resulting in different names to be chosen due to a race between app and kernel. In my particular case I send "reset" command to my device using terminal program through the /tty/USB0, device reboots and therefore disappears/appears back rather quickly. I then quit/re-run the application so that it re-opens the port (it remembers which one has been used last time), but device is now on /tty/USB1 :( Very annoying. Not that it's a huge problem, but I do feel somewhat uneasy about it. > > Can you think of a better way to handle this? No, not yet, -- I first wanted to see if there is some known show-stopper here. If nobody sees any fundamental thing why it shouldn't or just can't behave differently then now, I'll probably take a closer look at it. On the other hand, using udev rules to get stable names like /dev/usb/iProduct:iSerial could be a better idea even though there are other problems there, I think. -- Sergei. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
