Hotplug Driver Interface to User Level Programs: Some Questions.

Hotplug Driver Interface to User Level Programs: Some Questions.

[Alexander N. Kozhushkin]

    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?



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


-------------------------------------------------------
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
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Alan Stern]

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
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [linux-usb-devel] Hotplug Driver Interface to User Level Programs: Some Questions.

[David Brownell]

On Thursday 19 August 2004 8:32 am, Alan Stern wrote:
> On Thu, 19 Aug 2004, Alexander N. Kozhushkin wrote:
> 
> > 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.
> 
> As I understand it, the kernel should always use your option 3.  

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.

Other hotpluggable busses (or 2.4) may not act quite the same.

- Dave
 


-------------------------------------------------------
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
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Alexander N. Kozhushkin]

[-- 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 --]

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

[Alexander N. Kozhushkin]

David Brownell wrote:
> 
> On Thursday 19 August 2004 8:32 am, Alan Stern wrote:
> > On Thu, 19 Aug 2004, Alexander N. Kozhushkin wrote:
> >
> > > 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.
> >
> > As I understand it, the kernel should always use your option 3.
> 
> 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.
> 
> Other hotpluggable busses (or 2.4) may not act quite the same.
> 
> - Dave
> 
> The standard behavior should be: read, write, ioctl, fcntl, open,... 
> return ENODEV or something similar.  Close should return 0.
>
> Alan Stern

Hi,

Well, and what about the 'select()' system call?

   It is not a good idea  to make the 'select()' function fail if some
file  descriptor in  the  argument descriptor  sets  corresponds to  a
disconnected  device.  It is  much better  if the  'select()' function
treats  such   a  file   descriptor  as  if   it  is  ready   for  I/O
operations. Such a 'select()' function is more convenient in practice.

   Consider two  'select()' functions.  The first function  fails with
the  'ENODEV' error  code  if  some file  descriptor  in the  argument
descriptor  sets corresponds  to  a disconnected  device.  The  second
treats such  a file  descriptor as if  it is  valid and ready  for the
respective  I/O operation.  That is,  if some  element of  an argument
descriptor set corresponds to a disconnected device, then the function
adds that file descriptor to  the respective output descriptor set and
returns successfully. In this case,  the output of the second function
contains not only  the elements of the argument  descriptor sets which
are really ready for reading or writing or really have exceptions, but
also the elements  of those sets which correspond  to the disconnected
device.

   First,  if  a call  to  'select()'  completed  successfully, it  is
possible  that the  device which  corresponds to  some element  of the
output  descriptor   sets  has   been  disconnected  since   the  call
completion. So it is always  possible that some file descriptor in the
output descriptor sets is unusable for I/O operations. Therefore, if a
call  to  either  of  the  'select()' functions  above  has  completed
successfully and has modified  the argument descriptor sets, then each
file descriptor  in the modified  descriptor sets is either  ready for
the respective I/O  operation or unusable.  So the  results of all I/O
calls making use of the 'select()' results are still to be checked for
the 'ENODEV' error.

   Second, if a call to  the first 'select()' function has failed with
the 'ENODEV'  error code,  the application is  able to see  that there
exists a device which was disconnected.  However, ordinarily there are
several elements in the argument descriptor sets. So the result of the
call does  not provide the  application with any  reliable information
about  which file  descriptors in  the argument  descriptor  sets were
spoiled  by  the  disconnection.   The  information  returned  by  the
function in this  case is incomplete, and additional  system calls are
needed only to find those  spoiled file descriptors among the elements
of the argument descriptor sets.
   On the other hand, if some device was disconnected before a call to
the second  'select()' function, and  in the argument  descriptor sets
there are file descriptors which correspond to that device, then those
file  descriptors are  in the  respective output  descriptor  sets. It
should be noted  that a 'select()' call is  normally followed by calls
to  functions which  perform read  and  write operations  on the  file
descriptors in  the output  descriptor sets, i.e.,  on the  ready file
descriptors. As  noted before,  the results of  those calls are  to be
checked  for the  'ENODEV' error.  So, in  this case,  the information
provided by  the second 'select()' function is  usually sufficient not
only to  determine that  there is a  disconnected device, but  also to
find the unusable file descriptors in the argument descriptor sets and
to  distinguish between  them and  the  other elements  of the  output
descriptor sets which are actually ready for reading or writing.

   Moreover, if the second 'select()'  function is in use, it does not
matter whether a  file descriptor in the argument  descriptor sets was
spoiled before  a 'select()' call or  a file descriptor  in the output
descriptor sets was  spoiled immediately after it. In  either case the
device disconnection  which spoiled the file descriptor  is handled in
the  same way.   Instead of  checking the  'select()' results  for the
'ENODEV' error and doing excessive  system calls only to find unusable
file descriptors,  the application performs the calls  to 'read()' and
'write()' on the file  descriptors in the respective output descriptor
set and checks the results of  those read and write operations for the
'ENODEV' error,  as usually.  Those  'read()' and 'write()'  calls are
used  to  perform  I/O  operations  and  to  find  the  unusable  file
descriptors at the same time.

   Therefore, the  results of the second 'select()'  function are more
suitable in  practice than  the results  of the first  one, and  so it
seems that the  following behavior of the 'select()'  function is more
reasonable:
If a device was disconnected  after a file descriptor corresponding to
the device was  created, that file descriptor is  assumed to be always
ready for  reading and writing; the  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 the
'select()' function as an  argument, then the 'select()' function adds
the  file  descriptor to  the  respective  output  descriptor set  and
returns successfully.  In such a situation, the normal return value is
clearly greater than 0, instead of "-1".


Sincerely yours,
		A.N. Kozhushkin.



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


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Linas Vepstas]

On Sun, Sep 12, 2004 at 04:33:13AM +0400, Alexander N. Kozhushkin was heard to remark:
> 
>     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.

Please don't gzip the patches, and please use 'unified diff' format 
(diff -up), this makes it easier to read the patch.

>     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.

What happens if the x-server is connected directly to the mouse?  Can
I unplug one mouse, and plug in a different mouse and still have it
work?  I think you might want to cc the appropriate mailing list on
x.org about this. 

---
Another alkternative to returning -ENODEV is to have a zero-length read.
This is a traditional unix way of signifying that the remote end has
disconnected; e.g. for tcp sockets.  That is, select() will tell you
that there is something to read, and the read() call will suceed
(without error), and return zero bytes read.  For tcp, this is
understood to mean that the far side has closed its socket.

I'm not sure, but maybe this would also make sense for any USB device
that can be read with open(), read() calls? 

--linas



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Oliver Neukum]

Am Montag, 13. September 2004 21:27 schrieb Linas Vepstas:
> Another alkternative to returning -ENODEV is to have a zero-length read.
> This is a traditional unix way of signifying that the remote end has
> disconnected; e.g. for tcp sockets.  That is, select() will tell you
> that there is something to read, and the read() call will suceed
> (without error), and return zero bytes read.  For tcp, this is
> understood to mean that the far side has closed its socket.
> 
> I'm not sure, but maybe this would also make sense for any USB device
> that can be read with open(), read() calls? 

Unfortunately that would violate POSIX. Quote:

When attempting to read a file (other than a pipe or FIFO) that supports non-blocking reads and has no data currently available:
*If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN].
*If O_NONBLOCK is clear, read() shall block the calling thread until some data becomes available.
*The use of the O_NONBLOCK flag has no effect if there is some data available.

If you need to modify applications, you can just as well return
a proper error.

	Regards
		Oliver



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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

[Vojtech Pavlik]

On Sun, Sep 12, 2004 at 04:33:13AM +0400, Alexander N. Kozhushkin wrote:

>     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.

This is intentional, as the only reason for mousedev to exist are old
application that cannot use the event interface (which has the third
approach semantics).

There are applications (IIRC old versions of qtembedded and others) that
break when read on a PS/2 device returns an error. Hence we can't.

>     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.

Well, I think it'd be better if X and GPM were modified to use the event
interface, which would remove several more limitations (like the number
of buttons on a mouse).

> 
> Sincerely yours,
> 		Alexander.
> 
> 
> -- 
> *********************************************************
>                 Alexander N. Kozhushkin.
>             ADDR: alex@grave.users.botik.ru
> *********************************************************

> 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.



-- 
Vojtech Pavlik
SuSE Labs, SuSE CR


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel