Date: Tue, 10 Dec 2002 17:33:23 +0300
From: Yar Tikhiy <yar@FreeBSD.ORG>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: "Kenneth D. Merry" <ken@kdm.org>, Nate Lawson <nate@root.org>, freebsd-scsi@FreeBSD.ORG
Subject: Re: {da,sa,...}open bug?
Message-ID: <20021210173322.C27181@comp.chem.msu.su>
In-Reply-To: <2179138112.1039414275@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sun, Dec 08, 2002 at 11:11:15PM -0700
References: <20021206145942.I80257@comp.chem.msu.su> <Pine.BSF.4.21.0212061121290.15885-100000@root.org> <20021206123401.A23249@panzer.kdm.org> <2179138112.1039414275@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021210173322.C27181>