From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 08:59:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E1337B401 for ; Thu, 22 May 2003 08:59:08 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBC043F93 for ; Thu, 22 May 2003 08:59:07 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4MFwsrN038829 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 22 May 2003 17:58:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4MFwpOs021356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 May 2003 17:58:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h4MFwp5i001407; Thu, 22 May 2003 17:58:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h4MFwoCP001406; Thu, 22 May 2003 17:58:50 +0200 (CEST) Date: Thu, 22 May 2003 17:58:50 +0200 From: Bernd Walter To: Terry Lambert Message-ID: <20030522155850.GY501@cicely12.cicely.de> References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> <3ECCEEF5.2CF956D@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECCEEF5.2CF956D@mindspring.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-BETA alpha User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Jay Cornwall cc: ticso@cicely.de cc: Julian Elischer Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 15:59:09 -0000 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