Date: Tue, 10 Dec 2002 14:39:54 +0300
From: Yar Tikhiy <yar@freebsd.org>
To: Nate Lawson <nate@root.org>
Cc: freebsd-scsi@freebsd.org
Subject: Re: {da,sa,...}open bug?
Message-ID: <20021210143954.B14989@comp.chem.msu.su>
In-Reply-To: <Pine.BSF.4.21.0212091350460.25027-100000@root.org>; from nate@root.org on Mon, Dec 09, 2002 at 01:52:23PM -0800
References: <20021208182706.B75509@comp.chem.msu.su> <Pine.BSF.4.21.0212091350460.25027-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021210143954.B14989>