cvs commit: src/sys/dev/usb ugen.c
Brian Fundakowski Feldman
green at FreeBSD.org
Tue Oct 19 23:10:28 PDT 2004
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
> 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):
(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. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the cvs-all