From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:57:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 A950916A41F; Mon, 1 Aug 2005 19:57:53 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C205A43D48; Mon, 1 Aug 2005 19:57:52 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j71JvmBS062280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 21:57:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j71JveJ7014092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 21:57:41 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j71Jve6q065051; Mon, 1 Aug 2005 21:57:40 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71Jvdh5065050; Mon, 1 Aug 2005 21:57:40 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 21:57:39 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801195739.GF26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> <20050801184731.GD26656@cicely12.cicely.de> <494025505080112043f8a0554@mail.gmail.com> <20050801192000.GE26656@cicely12.cicely.de> <494025505080112441ac23dfa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494025505080112441ac23dfa@mail.gmail.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: Marc Olzheim , freebsd-hackers@freebsd.org, ticso@cicely.de Subject: Re: O_NONBLOCK for devices with removable media X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 01 Aug 2005 19:57:53 -0000 On Mon, Aug 01, 2005 at 10:44:46PM +0300, victor cruceru wrote: > See below. > > On 8/1/05, Bernd Walter wrote: > > > > On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: > > device requiring GIANT or any other lock. > > You can't open any kind device without a risk to block for a very > > short time. > > > It is OK if this is short (10-20 ms). Well - you have an USB frame every ms, so you can have multiple transactions in that time. One can really expect a device to react within that time. > But still you are talking about a broken device - replace or fix it > > and return to real problems. > > > Yes, this it is maybe true, but why to block in a driver if the user told > not to do it? Because progammers asumed non broken devices? > On the other hand all the HW is broken somehow... So this O_NONBLOCK should > be a way to deal with this kind of silly devices. Yes, ut USB devices are sometime horribly broken. It is really the question if we want workarouds for all and everything possible. Theoretically you can have a short timeout for such a request, but its complicated to handle USB timeouts for umass devices - you need to resync the whole transmission channel, which efefctivly is very much like a device reset. AFAIK these kind of resets are done in sync, so you still would block just to do the reset, which take seconds. On the other hand this would non-block the open call, but still not open the device, so you just stop the application from using it. > Really - a disk should know if it is ready or not and I won't call > > it blocking if you ask a disk about it. > > > > If you want a workaround then fork another process opening the device > > for you and passing the descriptor back to you via domain socket. > > > This is too complicated to be useful. Maybe to spawn a thread - this is also > too complicated for getting the capacity of a damn media (this is my > situation). This is less complicated than a kernel workaround and it even allows to use the device. But yes, it's still evil. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de