Date: Thu, 22 May 2003 08:38:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: ticso@cicely.de Cc: Jay Cornwall <jay@evilrealms.net> Subject: Re: USB bulk read & pthreads Message-ID: <3ECCEEF5.2CF956D@mindspring.com> References: <Pine.BSF.4.21.0305201638000.22764-100000@InterJet.elischer.org> <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECCEEF5.2CF956D>