On Sat, 2008-05-24 at 16:56 +0200, Christian Zachariasen wrote: > On Sat, May 24, 2008 at 4:48 PM, Coleman Kane <[EMAIL PROTECTED]> > wrote: > > On Sat, 2008-05-24 at 11:20 +0100, Robert Watson wrote: > > Dear all: > > > > Just as a reminder, we've just about reached the one month > date before > > IFF_NEEDSGIANT drivers are disabled in the build. You can > find a description > > of the general problem and list of specific drivers below. > > > > As USB work is on-going, I will *not* disable the USB > drivers at this time, > > but all other drivers in the list below will be disabled on > 26 June. They > > will remain in the tree, easily accessible for patch > distribution and > > re-enabling, until October, when any remaining non-MPSAFE > drivers will be > > deleted in 8.x. FreeBSD 8.0 will not ship with > compatibility shims to support > > non-MPSAFE network device drivers. > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > > ---------- Forwarded message ---------- > > Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) > > From: Robert Watson <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: 8.0 network stack MPsafety goals (fwd) > > > > > > Only a few days after predicted, this is a reminder that > IFF_NEEDSGIANT network > > drivers are going to stop working in the forseeable future. > Please review the > > attached driver list, and if you depend on or care about a > Giant-dependent > > device driver, take action to make sure it doesn't remain on > the list in a > > month's time! > > > > (As far as I'm aware, the list has not changed since my > December posting.) > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > > ---------- Forwarded message ---------- > > Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) > > From: Robert Watson <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: 8.0 network stack MPsafety goals > > > > > > Dear all: > > > > With the 7.0 release around the corner, many developers are > starting to think > > about (and in quite a few cases, work on) their goals for > 8.0. One of our > > on-going kernel projects has been the elimination of the > Giant lock, and that > > project has transformed into one of optimizating behavior on > increasing numbers > > of processors. > > > > In 7.0, despite the noteworth accomplishment of eliminating > debug.mpsasfenet > > and conditional network stack Gian acquisition, we were > unable to fully > > eliminate the IFF_NEEDSGIANT flag, which controls the > conditional acquisition > > of the Giant lock around non-MPSAFE network device drivers. > Primarily these > > drivers are aging ISA network device drivers, although there > are some > > exceptions, such as the USB stack. > > > > This e-mail proposes the elimination of the IFF_NEEDSGIANT > flag and associated > > infrastructure in FreeBSD 8.0, meaning that all network > device drivers must be > > able to operate without the Giant lock (largely the case > already). Remaining > > drivers using the IFF_NEEDSGIANT flag must either be > updated, or less ideally, > > removed. I propose the following schedule: > > > > Date Goals > > ---- ----- > > 26 Dec 2007 Post proposed schedule for flag and > infrastructure removal > > Post affected driver list > > > > 26 Jan 2008 Repost proposed schedule for flag and > infrastructure removal > > Post updated affected driver list > > > > 26 Feb 2008 Adjust boot-time printf for affect drivers to > generate a loud > > warning. > > Post updated affected driver list > > > > 26 May 2008 Post HEADS UP of impending driver disabling > > Post updated affected driver list > > > > 26 Jun 2008 Disable build of all drivers requiring > IFF_NEEDSGIANT > > Post updated affected driver list > > > > 26 Sep 2008 Post HEADS up of impending driver removal > > Post updated affected driver list > > > > 26 Oct 2008 Delete source of all drivers requiring > IFF_NEEDSGIANT > > Remove flag and infrastructure > > > > Here is a list of potentially affected drivers: > > > > Name Bus Man page description > > --- --- -------------------- > > ar ISA/PCI synchronous Digi/Arnet device driver > > arl ISA Aironet Arlan 655 wireless network > adapter driver > > awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA > wireless network > > driver > > axe USB ASIX Electronics AX88172 USB Ethernet > driver > > cdce USB USB Communication Device Class > Ethernet driver > > cnw PCCARD Netwave AirSurfer wireless network > driver > > cs ISA/PCCARD Ethernet device driver > > cue USB CATC USB-EL1210A USB Ethernet driver > > ex ISA/PCCARD Ethernet device driver for the Intel > EtherExpress > > Pro/10 and Pro/10+ > > fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based > Ethernet adapters > > ic I2C I2C bus system > > ie ISA Ethernet device driver > > kue USB Kawasaki LSI KL5KUSB101B USB Ethernet > driver > > oltr ISA/PCI Olicom Token Ring device driver > > plip PPBUS printer port Internet Protocol driver > > ppp TTY point to point protocol network > interface > > ray PCCARD Raytheon Raylink/Webgear Aviator > PCCard driver > > rue USB RealTek RTL8150 USB to Fast Ethernet > controller driver > > rum USB Ralink Technology USB IEEE 802.11a/b/g > wireless > > network device > > sbni ISA/PCI Granch SBNI12 leased line modem driver > > sbsh PCI Granch SBNI16 SHDSL modem device > driver > > sl TTY slip network interface > > snc ISA/PCCARD National Semiconductor DP8393X SONIC > Ethernet adapter > > driver > > sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 > device driver > > udav USB Davicom DM9601 USB Ethernet driver > > ural USB Ralink Technology RT2500USB IEEE > 802.11 driver > > xe PCCARD Xircom PCMCIA Ethernet device driver > > zyd USB ZyDAS ZD1211/ZD1211B USB IEEE > 802.11b/g wireless > > network device > > > > In some cases, the requirement for Giant is a property of a > subsystem the > > driver depends on as the driver itself; for example, the tty > subsystem for SLIP > > and PPP, and the USB subsystem for a number of USB ethernet > and wireless > > drivers. With most of a year before to go on the proposed > schedule, my hope is > > that we will have lots of time to address these issues, but > wanted to get a > > roadmap out from a network protocol stack architecture > perspective so that > > device driver and subsystem authors could have a schedule in > mind. > > > > FYI, the following drivers also reference IFF_NEEDSGIANT, > but only in order to > > provide their own conditional MPSAFEty, which can be removed > without affecting > > device driver functionality (I believe): > > > > Name Bus Man page description > > --- --- -------------------- > > ce PCI driver for synchronous Cronyx > Tau-PCI/32 WAN adapters > > cp PCI driver for synchronous Cronyx Tau-PCI > WAN adapters > > ctau ISA driver for synchronous Cronyx Tau WAN > adapters > > cx ISA driver for synchronous/asynchronous > Cronyx Sigma WAN > > adapters > > > > Developers and users of the above drivers are heavily > encouraged to update the > > drivers to remove dependence on Giant, and/or make other > contingency plans. > > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > I've created a quick table of these at the following location: > http://wiki.freebsd.org/NetworkNeedsGiant > > Please everyone feel free to fill in the blanks. I'll try to > do it as > well as time permits. > > -- > Coleman Kane > > Just out of curiousity - is there a guide available that gives some > pointers on how to go about removing the GIANT-parts of the drivers? > What would one replace it with? I'm not sure I would be up to the > task, but I'd find it interesting to actually understand the process. > > > > Christian Zachariasen
Various network drivers are IFF_NEEDSGIANT for different reasons. However, there are families of drivers that do share common root causes for MPUNSAFE-ness. One of these is the USB-based drivers, which require an MPSAFE USB stack to become MPSAFE themselves (a project which needs help). The TTY-based drivers, likewise, need an MPSAFE TTY implementation, which I've been told is forthcoming. I am hoping that this table I've posted can help answer your question. There are a number of drivers which require the Giant lock and I'd like to know why (in table form) so that this information can be compared. For instance, it could be that one person is working on fixing up one driver for MPSAFE operation, but their solution to that driver could possibly be easily applied to 5 others. It would be great if they knew that so that they could give pointers to interested persons such as yourself. Feel free to ping the author(s)/maintainer(s) of the various drivers in question, and point them at this list. As the spaces are filled, the solution will hopefully become more clear. -- Coleman Kane
signature.asc
Description: This is a digitally signed message part