Date: Sun, 08 Dec 2002 23:11:15 -0700
From: "Justin T. Gibbs" <gibbs@scsiguy.com>
To: "Kenneth D. Merry" <ken@kdm.org>, Nate Lawson <nate@root.org>
Cc: Yar Tikhiy <yar@FreeBSD.ORG>, freebsd-scsi@FreeBSD.ORG
Subject: Re: {da,sa,...}open bug?
Message-ID: <2179138112.1039414275@aslan.scsiguy.com>
In-Reply-To: <20021206123401.A23249@panzer.kdm.org>
References: <20021206145942.I80257@comp.chem.msu.su> <Pine.BSF.4.21.0212061121290.15885-100000@root.org> <20021206123401.A23249@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. -- Justin 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?2179138112.1039414275>