From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 1 17:31:52 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 958D516A41F; Mon, 1 Aug 2005 17:31:52 +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 78FCE43D48; Mon, 1 Aug 2005 17:31:51 +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 j71HVlBS058423 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 1 Aug 2005 19:31:49 +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 j71HUrJ7013214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2005 19:30:54 +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 j71HUr2u064185; Mon, 1 Aug 2005 19:30:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j71HUmpo064184; Mon, 1 Aug 2005 19:30:48 +0200 (CEST) (envelope-from ticso) Date: Mon, 1 Aug 2005 19:30:48 +0200 From: Bernd Walter To: soc-victor@freebsd.org Message-ID: <20050801173047.GC26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494025505080106336a329bb@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 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 17:31:52 -0000 On Mon, Aug 01, 2005 at 04:33:23PM +0300, victor cruceru wrote: > Hi Marc, > Thanks for the info. Here it is one my situation. I have a CF reader (fully > detected by the USB subsystem) with two slots > (one with a media and one without any media). An open with O_NONBLOCK on the > empty slot (/dev/da1) is blocking me. It should not block for a long time since the device should directly reply with either ready or no media. > Is this OK? No, but it is a broken device if you don't get back in a resonable time. I don't think that O_NONBLOCK is ment to never block for a short time. In case of disks you have to ask the device for ready state, if you don't allow blocking you can't do that and therefor never successfull open a disk. The intention should read more in the sense of, don't wait for a disk to spin up, but even this is problematic to implement correct with many devices. > On 8/1/05, Marc Olzheim wrote: > > > > On Mon, Aug 01, 2005 at 02:42:21PM +0300, victor cruceru wrote: > > > Hi all, > > > I'm just wondering if it's OK for an open syscall on such a device (i.e. > > > /dev/acd0 or /dev/da1 with a CF reader attached) to block till the media > > is > > > ready or a timeout occurs. > > > > I'd say that depends completely on whether you supply O_NONBLOCK or not, > > so yes. > > > > Quoted from a sound driver discussion at: > > http://sourceforge.net/mailarchive/message.php?msg_id=10011826 > > > > > > On block devices, O_NONBLOCK also is a way to say "don't try to do any > > device discovery", ie you can do a O_NONBLOCK open on a removable disk > > that doesn"t even have any media in it. Again, this has _nothing_ to do > > with whether the device is "busy" or not. > > > > ... > > > > Short summary: > > > > - O_NONBLOCK should generally be seen as just setting the O_NONBLOCK flag > > "early" (ie it"s conceptually equivalent to doing a "F_SETFL" fcntl > > before the open. It _may_ affect the open itself, but when it does, it > > is generally considered to mean that you can open something that isn't > > even _reachable_. > > > > - POSIX doesn't say anything much about its behaviour, except for named > > pipes, where it says the total reverse of what ALSA does. But that > > doesn't actually mean anything, because even that is very much defined > > as a special case by POSIX. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de