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>