On Thu, 19 Aug 2004, Alexander N. Kozhushkin wrote: > My experience of using Linux kernels 2.6 shows that there is some > problem with hotplug devices. Namely, it seems that, there is no > uniform approach of how an application performing I/O operations on a > device must be handled, when that device is disconnected. > > The following consideration explains the problem. Consider a > process, which is performing a system call with a file descriptor as > an argument. The file descriptor corresponds to a device special > file, and the device was disconnected after the descriptor was > created. > There are three reasonable ways by which the process can be handled: > 1. If the call involves an I/O operation on the device, the process > hangs indefinitely until a signal has terminated the call or the > process. > 2. If the call involves an I/O operation on the disconnected device, > the process waits for the device. As soon as the device is > connected again, an initialization procedure will put the device > into an appropriate state and will make the stopped process > continue. If the call does not involve I/O operations on the > device, it is performed without waiting, as if the device is > presented. In any case the process is able to complete the call > successfully. > 3. The call completes without waiting for the device. The file > descriptor has been unusable for I/O operations on the device since > the disconnection, therefore the result of the call is not affected > if the device has been connected again. The result of the call > depends on the kind of the called function and other conditions. > However, the 'close' function closes the file, and there are system > calls which produce a specific error code in such situations. > > In addition to the above, in many cases it is useful to deliver a > signal to a selected process at the moment when the device becomes > disconnected. > > The choice of the standard affects not only the kernel itself, but > also applications. The third approach looks like the most reasonable > one, it is proposed in the 'drivers/usb/usb-skeleton.c' file, however, > all of the approaches above are in use now. > > Which approach is the standard one or is supposed to be the standard? > > What is the standard behavior of the 'read()', 'write()', 'ioctl()', > 'select()', 'fcntl()', 'close()', ... system calls in such a > situation?
As I understand it, the kernel should always use your option 3. I'm not aware that any of the other options are in use anywhere; can you provide a list? The standard behavior should be: read, write, ioctl, fcntl, open,... return ENODEV or something similar. Close should return 0. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
