Date: Mon, 18 Jul 2005 23:56:08 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: arch@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 Message-ID: <20050718235043.Y15510@fledge.watson.org> In-Reply-To: <42DC08A4.2060001@samsco.org> References: <20050718183717.N9430@fledge.watson.org> <42DC08A4.2060001@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Jul 2005, Scott Long wrote: >> if_fxp Intel EtherExpress PRO/100 Ethernet device driver. >> Mutexes present and exercised; not marked IFF_NEEDSGIANT, >> but not marked INTR_MPSAFE (see if_fxpvar.h#define). >> Also, Giant passed into busdma for call-back lock. Maybe >> we can just throw the switch? > > bus_dmamap_load_mbuf() doesn't do deferalls, so the mutex argument in > the tag is unused in this case. Don't take it as an indication of > Giant-ness. It would be good to put an appropriate lock into the tag in > case it's needed in the future. Or the lock arg can just be set to > NULL, NULL for now. It sounds like a class of drivers needs testing with INTR_MPSAFE, but may well be pretty close to right. >> if_nve NVIDIA nForce MCP Networking Adapter device driver. >> Mutexes present and exercised; not marked IFF_NEEDSGIANT, >> but not marked INTR_MPSAFE. Also, busdma callbacks >> reference Giant. Maybe we can just throw the switch? > > This driver has many many more problems that just locking. Bjoern Zeeb has mentioned to me that he has a significant work-in-progress cleaning this driver up. >> if_owi Lucent Hermes, Intersil PRISM and Spectrum24 IEEE 802.11 >> driver (old). Mutexes present and exercised, not marked >> MPSAFE. > > Actually, I think that owi can be removed for 7.0. Maybe even 6.0. It > only existed as a stopgap for the 802.11 framework transition. I'll let you or Warner put this driver out of its misery, then. >> if_aue, if_axe, if_cdce, if_cue, if_kue, if_rue, if_udav, if_ural >> Countless USB device drivers -- locking present, >> exercised, but all running under Giant, presumably due to >> the USB framework. Someone has a big TODO item here. > > I don't think that we can assume that USB will get fixed for 7.0. It > would be nice if it does, but we shouldn't plan to orphan these drivers > because of it. If we can get the non-MPSAFE network driver set down to just the USB drivers, that's probably sufficient to move the Giant work-arounds into just that driver set, and not have it in the network stack in general. My goals with 7.x and the network stack MPSAFEty are really to clean up the architecture, catch many of the edge cases and areas of uncleanliness, etc. However, this will involve relying on drivers to lock some fields of ifnet, etc, which in turn relies on the drivers being synchronized properly. These sorts of cleanups really rely on drivers universally being self-synchronizing, even if that just means the workarounds move into a small set of drivers and out of the stack. Certainly the barrier to entry for any new network interface drivers is now that it must be MPSAFE. This means no more "close" cases like if_nve, which appears to run MPSAFE in one direction, but not the other, and possibly only by accident in that case? Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050718235043.Y15510>