From owner-freebsd-scsi Tue Dec 10 3:40:11 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9443537B401 for ; Tue, 10 Dec 2002 03:40:10 -0800 (PST) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6580E43EC2 for ; Tue, 10 Dec 2002 03:40:06 -0800 (PST) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3/8.12.3) with ESMTP id gBABdwm2019975; Tue, 10 Dec 2002 14:39:58 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3/8.12.3/Submit) id gBABdsio019974; Tue, 10 Dec 2002 14:39:54 +0300 (MSK) Date: Tue, 10 Dec 2002 14:39:54 +0300 From: Yar Tikhiy To: Nate Lawson Cc: freebsd-scsi@freebsd.org Subject: Re: {da,sa,...}open bug? Message-ID: <20021210143954.B14989@comp.chem.msu.su> References: <20021208182706.B75509@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nate@root.org on Mon, Dec 09, 2002 at 01:52:23PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Dec 09, 2002 at 01:52:23PM -0800, Nate Lawson wrote: > On Sun, 8 Dec 2002, Yar Tikhiy wrote: > > On Fri, Dec 06, 2002 at 11:23:56AM -0800, Nate Lawson wrote: > > > You are correct. Ok to commit this w/ re@ approval The other periphs > > > don't use this flag. > > > > While writing a message to re@, I thought if we were propagating > > bad style with such patches. Wouldn't it be better to set the open > > flag and acquire the periph if and only if returning success? The > > open flag seems to be of no use before the return from daopen(). > > This patch is bad since you need to move the acquire earlier, not > later. By moving it to the end, you increase the window where another > proc could release the periph and free it. Why, is the knowledge that cam_periph_lock() calls cam_periph_acquire() first of all considered secret? :-) The idea behind my patch was as follows: having called cam_periph_lock() ensures the periph won't disappear while it's being opened; and if the open succeeds, another reference to the periph is obtained so it won't go away until it's closed, and the former reference is released, which is one of cam_periph_unlock() effects. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message