From owner-freebsd-scsi Tue Dec 10 6:33:31 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 606A037B401 for ; Tue, 10 Dec 2002 06:33:29 -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 23BB643E4A for ; Tue, 10 Dec 2002 06:33:28 -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 gBAEXOm2030074; Tue, 10 Dec 2002 17:33:24 +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 gBAEXNfd030073; Tue, 10 Dec 2002 17:33:23 +0300 (MSK) Date: Tue, 10 Dec 2002 17:33:23 +0300 From: Yar Tikhiy To: "Justin T. Gibbs" Cc: "Kenneth D. Merry" , Nate Lawson , freebsd-scsi@FreeBSD.ORG Subject: Re: {da,sa,...}open bug? Message-ID: <20021210173322.C27181@comp.chem.msu.su> References: <20021206145942.I80257@comp.chem.msu.su> <20021206123401.A23249@panzer.kdm.org> <2179138112.1039414275@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2179138112.1039414275@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sun, Dec 08, 2002 at 11:11:15PM -0700 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 Sun, Dec 08, 2002 at 11:11:15PM -0700, Justin T. Gibbs wrote: > > Yar asked me to review his previous patch to a number of peripheral > > drivers that modifed the acquire/unlock/etc. order. I've asked Justin to > > take a look at it as well (thus the reason I haven't completed the review > > yet), ... > > The patches look okay to me. Although the lock API was never fully > implemented, it was indended to guarantee exclusive access to an underlying > device while the lock is held. This is exactly what you might want during > a device driver probe where multiple device drivers can attach > simultaneously > to the same device (e.g. pass and da both attach to direct access devices). > 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(); > > /* > * Perform probe. > */ > > /* > * Play nice with others. > */ > cam_periph_unlock(); > > return (0); > > with the appropriate release's and unlocks in the error cases of course. > The lock and unlock calls would also be used in open during any device > validation checks that require exclusive access. 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.) -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message