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. 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). Maybe these locks should be adaptive or spin.... And IFNET_*LOCK() should remain for adding/removing ifnet struct to the global ifnet whose type is ifnethead. In case of ifqueue, it should not need to acquire its ifnet lock because ifqueue has its own mutex. -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message