USB bulk read & pthreads

[Bernd Walter]

On Thu, May 22, 2003 at 08:38:29AM -0700, Terry Lambert wrote:
> 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.

Who says it does not?
Non-blocking I/O is used silently inside the threading library.
What shall the library do with the error?
refuse read/write to the application which requested blocking I/O?
Or ignore this error and work with blocking I/O and potentially
block the entire process?
>From the pthread sematics the latter is the correct way and it is
the way it's handled right now.

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

Yes - that works if you know what to transfer.
But ugen doesn't know anything about what it transfers, therefor
it can't buffer.
See uftdi devices - every read contains 2 extra bytes containing
addition informations - if we buffer the userland driver might get
confused because it might request less data.
More evil - the thread library might aggregate or split at will.
In short: non-blocking I/O won't work for ugen bulk pipes.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso at bwct.de                                  info at bwct.de