Date: Tue, 10 Dec 2002 13:20:41 -0800 (PST)
From: Nate Lawson <nate@root.org>
To: Yar Tikhiy <yar@FreeBSD.ORG>
Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, "Kenneth D. Merry" <ken@kdm.org>, freebsd-scsi@FreeBSD.ORG
Subject: Re: {da,sa,...}open bug?
Message-ID: <Pine.BSF.4.21.0212101314290.28346-100000@root.org>
In-Reply-To: <20021210173322.C27181@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Dec 2002, Yar Tikhiy wrote: > On Sun, Dec 08, 2002 at 11:11:15PM -0700, Justin T. Gibbs wrote: > > If we were to follow the indended use of the API, the probe code would > > probably look like this: > > > > /* > > * Ensure periph is not de-allocated > > * out from under us. > > */ > > cam_periph_acquire(); > > > > /* > > * Gain exclusive access to the periph. > > */ > > cam_periph_lock(); > > Do you imply that the feature that cam_periph_lock() calls > cam_periph_acquire() should not be relied upon? If it could be, > the driver could call cam_periph_lock() first, thus both locking > the device and ensuring its persistence, and invoke cam_periph_acquire() > then, only if long-term access to the device is necessary (e.g., a > device open routine would acquire the device until it's closed.) The two have different purposes: acquire -- atomically increase refcount so periph is guaranteed to not disappear under us lock -- ensure exclusive access to a periph The fact that lock calls acquire is just to keep the periph from disappearing while sleeping. If a periph is locked already, lock sleeps and depends on a wakeup from the proc that holds the lock calling unlock. If you look at unlock, it decrements the refcount using release and thus calling lock does NOT increase the refcount overall. You still need to call acquire separately. -Nate 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?Pine.BSF.4.21.0212101314290.28346-100000>