Re: [linux-usb-devel] Hotplug Driver Interface to User Level Programs: A

["Alexander N. Kozhushkin" <alex@grave.users.botik.ru>]

[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]

Alan Stern wrote:
> 
> 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?
> 
> Alan Stern

> Certainly USB should do it that way in 2.6, although the device
> drivers can try to implement other behavior.  I think that's made
> a big improvement in robustness.
>
> David Brownell

Hi,

    Unfortunately, now I cannot present  a full list of device drivers
which   use   the   first   and  second   approaches.   However,   the
"drivers/input/mousedev.c"  file by  Vojtech Pavlik  is an  example of
such a device driver. It  offers the first approach for the mouse-like
devices with  the minor numbers from 0  to 30, and the  second one for
the so-called "MOUSEDEV_MIX" device with minor number 31.

    Here is a  patch for kernel 2.6.7 which makes  that driver use the
third approach for the devices  with minor numbers 0--30. Most likely,
the patch  can be used  for kernels 2.6.8  and 2.6.9 too.  The archive
"tests.tgz" contains some  very simple programs to test  the patch and
the  original mouse  driver. The  description  of the  changes to  the
"mousedev.c" file can be found in the "patch.txt" file.

    The  'gpm' program, properly  rewritten by  me to  support hotplug
mice,  and the  above  tests work  reliably  on my  computer with  the
modified mouse driver. The X-server  works reliably too if it uses the
data supplied  by the  modified version of  the 'gmp', instead  of the
real mouse data.

Sincerely yours,
		Alexander.


-- 
*********************************************************
                Alexander N. Kozhushkin.
            ADDR: alex@grave.users.botik.ru
*********************************************************

[-- Attachment #2: patch.gz --]
[-- Type: application/x-gzip, Size: 1117 bytes --]

[-- Attachment #3: patch.txt --]
[-- Type: text/plain, Size: 2480 bytes --]

I have made the following changes to the "drivers/input/mousedev.c" file: 

1. 'mousedev_write()', 'mousedev_read()':
   The changes protect an application using the 'read()' function from
   waiting indefinitely  for a disconnected mouse.  If the application
   performs a read or write  operation on the disconnected device, the
   call  fails with  the 'ENODEV'  error  code. This  behavior of  the
   'read()'   and    'write()'   functions   is    proposed   in   the
   "drivers/usb/usb-skeleton.c" file.

2. 'mousedev_poll()':
   The changes  protect an  application using the  'select()' function
   from waiting  indefinitely for a  disconnected mouse. If  the mouse
   was  disconnected, each  file descriptor  of the  respective device
   file  is  assumed  to  be  always ready  for  reading.  The  device
   disconnection is assumed to be a permanent exceptional condition on
   the  file  descriptor. The  'select()'  function  treats that  file
   descriptor as a  valid and ready one. So if  the file descriptor is
   contained in a  descriptor set supplied to a  'select()' call as an
   argument, then the 'select()' function adds that file descriptor to
   the respective  output descriptor  set, i.e., sets  the appropriate
   bit of  the respective 'fd_set'  input variable.  In this  case the
   function  returns successfully.   The mouse  disconnection  and the
   unusable  file descriptor can  be easily  detected by  checking the
   results of  the successive  'read()' calls, which  make use  of the
   results of the 'select()' call, for the 'ENODEV' error.

3. 'mousedev_disconnect()':
   a) Sending a 'SIGIO' signal.
      This   'SIGIO'  signal   protects  an   application   using  the
      'sigsuspend()' function from  waiting indefinitely for a 'SIGIO'
      signal.  If a file  descriptor corresponds  to a  device special
      file representing a mouse, and  the 'O_ASYNC' status flag is set
      on that file descriptor, a  'SIGIO' signal is generated when the
      mouse becomes disconnected.
   b) The  pointers  in  the  'mousedev_table' are  used  only by  the
      'mousedev_open()'  and  'mousedev_connect()'  functions, so  the
      'mousedev_disconnect()' function  can safely remove  the pointer
      corresponding    to   the    disconnected    mouse   from    the
      'mousedev_table'.

4. 'mousedev_free()':
   The  line "mousedev_table[mousedev->minor] =  NULL;" is  moved into
   the 'mousedev_disconnect()' function.

[-- Attachment #4: tests.tgz --]
[-- Type: application/octet-stream, Size: 9146 bytes --]