Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 May 2003 17:58:50 +0200
From:      Bernd Walter <ticso@cicely12.cicely.de>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Julian Elischer <julian@elischer.org>
Subject:   Re: USB bulk read & pthreads
Message-ID:  <20030522155850.GY501@cicely12.cicely.de>
In-Reply-To: <3ECCEEF5.2CF956D@mindspring.com>
References:  <Pine.BSF.4.21.0305201638000.22764-100000@InterJet.elischer.org> <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> <3ECCEEF5.2CF956D@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@bwct.de                                  info@bwct.de



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030522155850.GY501>