From owner-freebsd-hackers@FreeBSD.ORG Thu May 22 08:39:50 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 4EA6437B401 for ; Thu, 22 May 2003 08:39:50 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9542C43F3F for ; Thu, 22 May 2003 08:39:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38ldva3.dialup.mindspring.com ([209.86.253.67] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19IsAN-0003Sl-00; Thu, 22 May 2003 08:39:40 -0700 Message-ID: <3ECCEEF5.2CF956D@mindspring.com> Date: Thu, 22 May 2003 08:38:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ticso@cicely.de References: <3ECB041D.4FE961D@mindspring.com> <20030521162339.GL21312@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44cd15d84a27b0bd7cc7d52e421f937eaa8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Julian Elischer cc: Jay Cornwall Subject: Re: USB bulk read & pthreads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list 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:39:50 -0000 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