From owner-freebsd-scsi Tue Dec 10 13:20:42 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 D665A37B404 for ; Tue, 10 Dec 2002 13:20:40 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4026543EDA for ; Tue, 10 Dec 2002 13:20:40 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 28470 invoked by uid 1000); 10 Dec 2002 21:20:41 -0000 Date: Tue, 10 Dec 2002 13:20:41 -0800 (PST) From: Nate Lawson To: Yar Tikhiy Cc: "Justin T. Gibbs" , "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? In-Reply-To: <20021210173322.C27181@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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