cvs commit: src/sys/dev/usb ugen.c

[Brian Feldman]

green       2004-10-13 04:12:20 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/usb          ugen.c 
  Log:
  Back out rev.1.91 which implemented bulk read transfers in ugen(4) as
  asynchronous.  I realize that this means the custom application will
  not work as written, but it is not okay to break most users of ugen(4).
  
  The major problem is that a bulk read transfer is not an interrupt
  saying that X bytes are available -- it is a request to be able to
  receive up to X bytes, with T timeout, and S short-transfer-okayness.
  
  The timeout is a software mechanism that ugen(4) provides and cannot
  be implemented using asynchronous reads -- the timeout must start at
  the time a read is done.
  
  The status of up to how many bytes can be received in this transfer
  and whether a short transfer returns data or error is also encoded
  at least in ohci(4)'s requests to the controller.  Trying to detect
  the "maximum width" results in using a single buffer of far too
  small when an application requests a large read.
  
  Even if you combat this by replacing all buffers again with the
  maximal sized read buffer (1kb) that ugen(4) would allow you to
  use before, you don't get the right semantics -- you have to
  throw data away or make all the timeouts invalid or make the
  short-transfer settings invalid.
  
  There is no way to do this right without extending the ugen(4) API
  much further -- it breaks the USB camera interfaces used because
  they need a chain of many maximal-width transfers, for example, and
  it makes cross-platform support for all the BSDs gratuitously hard.
  
  Instead of trying to do select(2) on a bulk read pipe -- which has
  neither the information on desired transfer length nor ability to
  implement timeout -- an application can simply use a kernel thread
  and pipe to turn that endpoint into something poll-able.
  
  It is unfortunate that bulk endpoints cannot provide the same semantics
  that interrupt and isochronous endpoints can, but it is possible to just
  use ioctl(USB_GET_ENDPOINT_DESC) to find out when different semantics
  must be used without preventing the normal users of the ugen(4) device
  from working.
  
  Revision  Changes    Path
  1.96      +31 -151   src/sys/dev/usb/ugen.c