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

[Brian Fundakowski Feldman]

On Wed, Oct 13, 2004 at 04:12:20AM +0000, Brian Feldman wrote:
> 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.

For what it's worth, it really isn't that hard to make your software
account for bulk-ugen(4)'s brain-deadedness; for example, I can use
this to do GPRS on my Treo with ppp(8):
	<http://green.homeunix.org/~green/ppp.ugen.patch>
(I guess it's also useful as a reference implementation for this sort
 of thing in PPP, in general -- it certainly exposes weaknesses.)
-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\