On Mon, 6 Jan 2003, Kyunghwan Kim wrote: > On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote: > > On Fri, 3 Jan 2003, Nate Lawson wrote: > > NL>I was looking into some "could sleep messages" and found some bogus > > NL>locking in the attach routine of many drivers. Several init a mtx in > > NL>their softc and then lock/unlock it in their attach routine. This, of > > NL>course, does nothing to provide exclusive access to a device. I assume > > NL>there is going to be a global IF_LOCK or something to be used in attach > > NL>routines. Can someone fill me in on the intended design? > > > > Probably not. I asked the same question a couple of month ago and got 0 > > answers. I think, there is no way, the driver itself can assure exclusive > > access to the device it is attaching. It *must* assume, that there is some > > kind of locking around the call to the attach routine. Getting the lock in > > the softc inside the attach routine may be neccessary, because the routine > > may call other functions that assume they have the lock. > > Only using lock in softc can't assure its exclusive access > because there are some cases of changing some values in ifnet struct > outside of device driver routines. > > Most of the NIC drivers don't have its own locks for now, and using > both IFNET_*LOCK() and its own softc lock can't make everything in sync.
My point. > There should be two use of locks IMO: one or more per-device locks > in driver softc for manipulating per-device private data protection, > and ifnet lock for each ifnet struct protection (such as ifnet.if_mtx). Looking further into sys/net/if.c, it appears that the list of interfaces is protected by IFNET_WLOCK in if_attach(). I think it's safe to work under the following assumptions: 1. newbus will not call an attach routine twice for the same hw 2. ifnet routines take care of themselves 3. per-device locking is only necessary to provide exclusive access within a given driver instance. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
