USB bulk read & pthreads

Terry Lambert tlambert2 at mindspring.com
Thu May 22 08:39:50 PDT 2003


Bernd Walter wrote:
> On Tue, May 20, 2003 at 09:44:13PM -0700, Terry Lambert wrote:
> > Or it's a bug in the USB driver, not honoring non-blocking I/O.
> 
> ugen(4) does not support non-blocking I/O like most other driver also do
> not.
> 
> I don't count it as a bug as noone ever told that it does.
> It's even documented in ugen(4):
>      The bulk transfer mode can be in or out depending on the endpoint.  To
>      perform I/O on a bulk endpoint read(2) and write(2) should be used.  All
>      I/O operations on a bulk endpoint are unbuffered.
> non-blocking requires buffered I/O.

Then it should produce an error when someone tries to enable
non-blocking I/O on it, and *that's* the bug.


> The device gets regulary polled if someone has an outstanding transfer.
> Implementing nonblocking I/O would require always to have an
> outstanding read for open devices - similar is done in ucom(4).

The way Vadim Antonov got around this in the BSDI ft(4) driver
for tape drives on floppy controllers was to provide a buffer
sufficient for the largest block of data that you could ever
transfer in one read with the driver, in both the read and write
directions, and decoupling them from the actual user read/write
requests in the strategy routine.  This avoided him needing to
do the evil of an outstanding read for open devices.

FWIW.

-- Terry


More information about the freebsd-hackers mailing list