From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 19:20: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 B215016A41F; Mon, 1 Aug 2005 19:20: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 6B8B643D49; Mon, 1 Aug 2005 19:20: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 j71JKmBS061528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 21:20: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 j71JK1J7013872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 21:20:02 +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 j71JK1id064837; Mon, 1 Aug 2005 21:20:01 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71JK1Zg064836; Mon, 1 Aug 2005 21:20:01 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 21:20:00 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801192000.GE26656@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494025505080112043f8a0554@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:20:53 -0000 On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: > In conclusion: > any difference between open with O_NONBLOCK and open without it for this > kind of devices? > Because man 2 open says: > ---------------------------------------------------------------------------------------------------- > If the O_NONBLOCK flag is specified and the open() system call would result > in > the process being blocked for some reason (e.g., waiting for carrier on a > dialup line), open() returns immediately. The descriptor remains in non- > blocking mode for subsequent operations. > ---------------------------------------------------------------------------------------------------- Then make it always fail for disk devices. I really don't know what you expect to win with this. There is no other choice. There are many short time blocks you won't noice, e.g. openeing a device requiring GIANT or any other lock. You can't open any kind device without a risk to block for a very short time. But still you are talking about a broken device - replace or fix it and return to real problems. 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. > On 8/1/05, Bernd Walter wrote: > > > > On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: > > > Well, if you are doing this from a daemon (multiplexing a lot of events) > > > which is blocked in this open syscall, even 1 second is not reasonable. > > In > > > my case it is something more than 30 of seconds (again, on a 5.4 box). > > I'll > > > give it a try on FreeBSD 6. I'm currently investigating if there is > > > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can be > > issued > > > on a control device (i.e. /dev/ata) > > > > What do you expect it to do? > > Ask the device about the state or always fail, because it is not > > allowed to ask the device? > > In your case you have a broken device, this isn't much of an argument. > > A resonable reply time for a USB device would be less then 10ms. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de