From owner-freebsd-arch@FreeBSD.ORG Mon Jul 18 18:59:02 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F38016A41C for ; Mon, 18 Jul 2005 18:59:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 143A143D45 for ; Mon, 18 Jul 2005 18:59:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6FE0146B04 for ; Mon, 18 Jul 2005 14:59:01 -0400 (EDT) Date: Mon, 18 Jul 2005 19:59:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: <20050718183717.N9430@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 18:59:02 -0000 Just in case you missed it, a significant activity in the FreeBSD source tree for the past five years has been SMPng, the movement from a single "Giant" lock around the kernel to alternative synchronization models that include atomic operations, fine-grained locking, per-CPU data structures, etc. A significant part of this work was to remove the Giant lock from the network stack, where it has now been largely removed. The remaining sections consist of: - Legacy network protocol code which needs to be removed or fixed. This includes KAME IPSEC (not FAST_IPSEC), some older ATM portions, and some tty-related parts (SLIP, kernel PPP). For most of these portions, which I'll send e-mail about in a week or two to cover the state of, we now either have owners or a plan. There are some notable exceptions. - A number of network device drivers, which run under a compatibility mode that requires acquiring Giant in the inbound path, and possibly deferring work to a Giant-holding context in the outbound path. This e-mail is about the second category -- device drivers which still run with or require Giant. These in turn can be broken out into two categories: - Device drivers that appear to have been modified to run MPSAFE, and are possibly running partly Giant-free (i.e., perhaps the outbound path but not interrupt handler, or vice versa). - Device drivers that haven't been touched and rely on Giant entirely. The plan for FreeBSD 7.0 (i.e., HEAD) is that all network device drivers will be required to *operate without Giant*. This is necessary because all network protocol parts will be running without Giant, and the compatibility shims that allow older device drivers to run with Giant will be removed. Obviously, the details are subject to discussion, but I thought it would be helpful to do a sweep of the drivers and identify ones that either require some further work, or are definitely on the chopping board. Nothing will be removed until within a few months of the RELENG_7 branch, so we have quite a bit of time (about a year) to get this cleaned up before device drivers start disappearing. This will not be my last e-mail on the topic, you will get intermittent updates on how things are going. Specifically, however: - All network device drivers should be running INTR_MPSAFE (exceptions for device driver frameworks that don't support it). - No network device drivers should be running IFF_NEEDSGIANT (possibly excepting device driver frameworks that don't support it). First, a list of device drivers in the "partly or mostly done" category. Some require a lot of testing and work; others require a bit of code deletion or changing a flag and a bit of testing. If you are the maintainer/owner of one of these drivers, or play one on TV, I would love to see this work done by the end of August. And ideally, I'd love to see it MFC'd to RELENG_6. In general, this is low-risk work. if_an Aironet Communications 4500/4800 wireless network adapter driver. Mutexes present and exercised; not marked IFF_NEEDSGIANT, but not marked INTR_MPSAFE. Maybe we can just throw the switch? if_cp Cronyx Tau-PCI WAN adapters -- runs MPSAFE, but still has frobts to run un-MPSAFE. That should be easy to fix. if_ct Cronyx-Tau adapter -- runs MPSAFE, but still has frobs to run un-MPSAFE. That should be easy to fix. if_cx Driver for synchronous/asynchronous Cronyx Sigma WAN adapters -- runs MPSAFE, but still has frobs to run un-MPSAFE. That should be easy to fix :-). if_dc Tulip driver -- mutexes present, not used unless IS_MPSAFE set to non-0, so un-exercised. if_el Ethernet driver for 3Com Etherlink 3C501 devices. Mutxes present and exercised, not marked MPSAFE. if_en Device driver for Midway-based ATM interfaces. Mutexes present and exercised; not marked IFF_NEEDSGIANT, but not marked INTR_MPSAFE. Maybe we can just throw the switch? if_fatm Device driver for Fore PCA200E ATM interfaces. Mutexes present and exercised; not marked IFF_NEEDSGIANT, but not marked INTR_MPSAFE. Maybe we can just throw the switch? 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? if_hatm Device driver for Fore/Marconi HE155 and HE622 ATM interfaces. Appears MPSAFE and ready to go, only it looks like it uses a non-default kenv value to key MPSAFEty. Maybe we can just throw the switch? if_hme Sun Microelectronics STP2002-STQ Ethernet interfaces device driver. Generally fine, but Giant referenced in budma callback. Can this be fixed easily? if_my Myson Technology Ethernet PCI driver. Mutexes present and exercised, not marked IFF_NEEDSGIANT, but not not marked INTR_MPSAFE. Maybe we can just throw the switch? 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? if_patm Device driver for IDT77252 based ATM interfaces (ProSum and IDT). Mutexes present and exercised, not marked IFF_NEEDSGIANT, but not marked INTR_MPSAFE. Maybe we can just throw the switch? if_pcn AMD Am79c972 fast ethernet PCI NIC driver. Mutexes present and exercised, not marked MPSAFE. if_pdq DEC PDQ FDDI Controller. Mutexes present and exercised. Not marked IFF_NEEDSGIANT, but also not marked INTR_MPSAFE. A property of EISA MPSAFEty? if_sf Adaptec AIC-6915 "Starfire" PCI fast ethernet driver. Mutexes present and exercised, not marked MPSAFE. if_ste Sundance Technologies ST201 Fast Ethernet device driver. Mutexes present and exercised, not marked MPSAFE. if_ti Alteon Networks Tigon PCI gigabit ethernet driver. Mutexes present and exercised, not marked MPSAFE. if_tl Texas Instruments ThunderLAN Ethernet device driver. Mutexes present and exercised, not marked MPSAFE. if_wb Winbond fast ethernet PCI NIC driver. Mutexes present and exercised, not marked MPSAFE. if_owi Lucent Hermes, Intersil PRISM and Spectrum24 IEEE 802.11 driver (old). Mutexes present and exercised, not marked MPSAFE. 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. if_wl T1 speed ISA/radio lan card. Mutexes present and exercised, not marked IFF_NEEDSGIANT, but not marked INTR_MPSAFE. Easy to fix? The second category was device drivers that basically haven't been touched at all with respect to synchronization since they were introduced into the tree, and in most cases, these drivers were introduced into the tree before SMPng began. These drivers are often aging ISA device drivers, and are often quite simple in structure so could be made MPSAFE quite easily, at least if you had the hardware on hand to test. There's probably quite a bit of this hardware floating around, so my expectation is that at least a third of these drivers will be made MPSAFE before I start having to start setting deadlines. If you have, or better yet, regularly use one of these drivers, please take a look at doing the work! Here they are: if_ar synchronous Digi/Arnet device driver -- has mutexes, but not used really. if_arl Aironet Arlan 655 wireless network adapter driver -- no locks at all. if_awi AMD PCnetMobile IEEE 802.11 PCMCIA wireless network driver -- no locks at all. if_cm SMC Arcnet Ethernet device driver -- no locks at all. if_cnw Netwave AirSurfer wireless network driver -- no locks at all. if_cs Crystal Semiconductor CS8900 and CS8920 NICs -- no locks at all. if_de DEC 21040 PCI Ethernet Controller -- no locks at all. if_ed NE-2000 and WD-80x3 Ethernet driver -- no locks at all. if_ex Ethernet device driver for the Intel EtherExpress Pro/10 and Pro/10+ -- macros defined, but no locking at all. if_fe Fujitsu MB86960A/MB86965A based Ethernet adapters -- no locks at all. if_fwe Ethernet emulation driver for FireWire -- no locks at all. if_fwip IP over FireWire driver -- no locks at all. if_gem ERI/GEM/GMAC Ethernet device driver -- no locks at all. if_harp Pseudo physical interface driver for HARP -- no locks at all. if_ie 8-bit and 16-bit ISA ethernet cards based on the Intel i82586 chip -- no locks at all. if_ic I2C bus IP driver -- no locks at all. if_lge Level 1 LXT1001 NetCellerator PCI Gigabit Ethernet adapter driver -- no locks at all. if_lnc AMD Lance/PCnet Ethernet device driver -- no locks at all. if_mn Unlocked netgraph node? if_oltr Olicom Token Ring device driver -- no locks at all. if_plip Printer port Internet Protocol driver -- no locks at all. if_ray Raytheon Raylink/Webgear Aviator PCCard driver -- no locks at all. if_sbsh Granch SBNI16 SHDSL modem device driver -- no locks at all. if_sbni Granch SBNI12 leased line modem driver -- no locks at all. if_snc National Semiconductor DP8393X SONIC Ethernet adapter driver -- no locks at all. if_sr Synchronous RISCom/N2 / WANic 400/405 device driver -- no locks at all. if_tx SMC 83c17x Fast Ethernet device driver -- no locks at all. if_txp 3Com 3XP Typhoon/Sidewinder (3CR990) Ethernet interface -- has mutexes, but they're not used. if_vx 3Com EtherLink III / Fast EtherLink III (3c59x) Ethernet driver -- no locks at all. if_xe Xircom PCMCIA Ethernet device driver -- no locks at all. This list might have a few mis-categorized, I might have missed a few device drivers, etc. If you are using a device driver and it's not marked MPSAFE, and it's also not on this list, you should still worry, and ideally do something about it. We have about a year -- that's lots of time, if people start now. :-) Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Mon Jul 18 19:53:07 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 264EC16A41C; Mon, 18 Jul 2005 19:53:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C66A43D48; Mon, 18 Jul 2005 19:53:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6IK3lwo008994; Mon, 18 Jul 2005 14:03:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42DC08A4.2060001@samsco.org> Date: Mon, 18 Jul 2005 13:53:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050718183717.N9430@fledge.watson.org> In-Reply-To: <20050718183717.N9430@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: arch@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 19:53:07 -0000 Robert Watson wrote: [...] > > if_dc Tulip driver -- mutexes present, not used unless IS_MPSAFE > set to non-0, so un-exercised. > As has been discussed, throwing the switch on this one is scary since the driver is so overloaded with parallel codepaths to handle slightly incompatible hardware. Also, mutex recursion was often a common problem with early locking attempts (due to the non-SMP-friendly design on miibus). Do we know if this driver suffers from this or not? > > 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. > > if_hme Sun Microelectronics STP2002-STQ Ethernet interfaces > device driver. Generally fine, but Giant referenced in > budma callback. Can this be fixed easily? See my comment on fxp. > > 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. > if_ti Alteon Networks Tigon PCI gigabit ethernet driver. > Mutexes present and exercised, not marked MPSAFE. I'm working on this one and using it as a testbed for alternate locking strategies. The downside to this driver is that the initialization code isn't quite right and results in making it very hard to use. > > 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. > > 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. [...] Scott From owner-freebsd-arch@FreeBSD.ORG Mon Jul 18 20:13:45 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29B8A16A41C; Mon, 18 Jul 2005 20:13:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C027643D45; Mon, 18 Jul 2005 20:13:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6IKBtRw084169; Mon, 18 Jul 2005 14:11:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 18 Jul 2005 14:12:40 -0600 (MDT) Message-Id: <20050718.141240.43007426.imp@bsdimp.com> To: rwatson@FreeBSD.ORG From: "M. Warner Losh" In-Reply-To: <20050718183717.N9430@fledge.watson.org> References: <20050718183717.N9430@fledge.watson.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.ORG Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 20:13:45 -0000 # here's my take on the list as the PC Card maintainer, with two side # comments about really old hardware. In message: <20050718183717.N9430@fledge.watson.org> Robert Watson writes: : These drivers are often aging ISA device drivers, and Many of these are also PC Card devices. For wired Ethernet devices, I'd say that NE-200 cards (ed) are the most popular, 3Com cards (ep) are next. Then Xircom cards (xe). Then there's a bit of a gap in popularity and you have fe/sn as the next most popular (not sure which is more popular, maybe fe). Then a huge gap for the stragglers: cs, ex, snc. So here's my breakdown of the PC Card drivers in terms of importants for currently readily available hardware: Tier 1 Gotta do, or we'll get boatload of complaints ed, xe, an Tier 2 Really nice to have. People will notice. fe, sn Tier 3 Only Warner would notice, unless we remove it in which case more folks would notice. cs, ex Tier 4 Anybody using these at all? If not, time to die? awi, cnw, ray, owi (note: Tiers are just a word here, not a formalism ala the handbook) I've not considered what ISA cards might still be in use and popular, and this is my own opinion. And I'm offering it up as a guide to those folks casting about for projects to do. Please don't take it as a demand on anybdoy's time. Look at it as feedback for setting priorities. I'll likely also do some locking myself, but I'm not going to block anybody by saying which drivers :-) My detailed comments about the hardware follow. The vx driver is the only one that's not a PC Card that I've commented on since it is related to a PC Card driver. Well, and the humble wl driver. : if_an Aironet Communications 4500/4800 wireless network adapter : driver. Mutexes present and exercised; not marked : IFF_NEEDSGIANT, but not marked INTR_MPSAFE. Maybe we can : just throw the switch? These are relatively popular cards. I think efforts should be made here as many are still in service. : if_owi Lucent Hermes, Intersil PRISM and Spectrum24 IEEE 802.11 : driver (old). Mutexes present and exercised, not marked : MPSAFE. This driver can be removed from the tree completely. And it only supports Hermes I cards :-). : 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. USB is indeed a huge todo item for someone. : if_wl T1 speed ISA/radio lan card. Mutexes present and : exercised, not marked IFF_NEEDSGIANT, but not marked : INTR_MPSAFE. Easy to fix? I have this hardware, but it is a pre-802.11 card with crappy performance compared to more modern hardware. I doubt anyone will care about it :-). It is an ISA card. : if_awi AMD PCnetMobile IEEE 802.11 PCMCIA wireless network : driver -- no locks at all. This is a 2MBps 802.11 card. I'd rate it a low priority. : if_cnw Netwave AirSurfer wireless network driver -- no locks at : all. This is a pre-802.11 card. I have two in my basement that I've not connected in about 4 years. No clue if the driver even works now, nor really any idea how to setup and test it. : if_cs Crystal Semiconductor CS8900 and CS8920 NICs -- no locks : at all. A few PC Cards made by IBM use this chip. : if_ed NE-2000 and WD-80x3 Ethernet driver -- no locks at all. The single most popular PC Card ethernet solution. We have *GOT* to get this done. It would be our number one priority of the PC Cards. : if_ex Ethernet device driver for the Intel EtherExpress Pro/10 : and Pro/10+ -- macros defined, but no locking at all. A few PC Cards were based on this. Including the only Ethernet + Serial cards I'm aware of. : if_fe Fujitsu MB86960A/MB86965A based Ethernet adapters -- no : locks at all. Popular cards in Japan for a while, so you can find these in the market for 500 yen, or could on my last trip to Japan. In the US they were sold, but are rarer. These are the forth most common card. : if_ray Raytheon Raylink/Webgear Aviator PCCard driver -- no locks : at all. These are 802.11 cards, but frequency hopping, not spread spectrum. I'd rate it as higher than cnw, but lower than awi. : if_snc National Semiconductor DP8393X SONIC Ethernet adapter : driver -- no locks at all. As far as I know, this is for a PC-98 PC Card. It can be made to work, I think, on x86, but I've had no luck with it. Fairly rare cards. : if_vx 3Com EtherLink III / Fast EtherLink III (3c59x) Ethernet : driver -- no locks at all. The alternative to locking this driver is adding DMA support to the ep driver. I know Matt Dodd has been talking about that for a while now.. : if_xe Xircom PCMCIA Ethernet device driver -- no locks at all. Fairly popular ethernet cards. I think efforts should be made here. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jul 18 22:56:04 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6738016A41C for ; Mon, 18 Jul 2005 22:56:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 157B543D46 for ; Mon, 18 Jul 2005 22:56:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 5831846B46; Mon, 18 Jul 2005 18:56:03 -0400 (EDT) Date: Mon, 18 Jul 2005 23:56:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <42DC08A4.2060001@samsco.org> Message-ID: <20050718235043.Y15510@fledge.watson.org> References: <20050718183717.N9430@fledge.watson.org> <42DC08A4.2060001@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 22:56:04 -0000 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 From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 08:15:18 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F47D16A41C; Tue, 19 Jul 2005 08:15:18 +0000 (GMT) (envelope-from martin@gneto.com) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EFC643D45; Tue, 19 Jul 2005 08:15:16 +0000 (GMT) (envelope-from martin@gneto.com) Received: from as6-1-5.kr.m.bonet.se ([83.227.181.30] [83.227.181.30]) by mxfep01.bredband.com with ESMTP id <20050719081515.WEKV11632.mxfep01.bredband.com@as6-1-5.kr.m.bonet.se>; Tue, 19 Jul 2005 10:15:15 +0200 Received: from [192.168.10.11] (euklides.gneto.com [192.168.10.11]) by as6-1-5.kr.m.bonet.se (Postfix) with ESMTP id B0E1B678B9; Tue, 19 Jul 2005 10:15:14 +0200 (CEST) Message-ID: <42DCB694.7030007@gneto.com> Date: Tue, 19 Jul 2005 10:15:16 +0200 From: Martin Nilsson User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050718183717.N9430@fledge.watson.org> In-Reply-To: <20050718183717.N9430@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 08:15:18 -0000 Robert Watson wrote: > if_el Ethernet driver for 3Com Etherlink 3C501 devices. > Mutxes present and exercised, not marked MPSAFE. This is an 8-bit ISA card that was a piss-poor-performer even when it was new. Please don't waste developer resources on things like this! /Martin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 08:31:52 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A365316A41C; Tue, 19 Jul 2005 08:31:52 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E5F543D58; Tue, 19 Jul 2005 08:31:52 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 44040BC83; Tue, 19 Jul 2005 08:31:50 +0000 (UTC) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 18 Jul 2005 19:59:04 BST." <20050718183717.N9430@fledge.watson.org> Date: Tue, 19 Jul 2005 10:31:50 +0200 Message-ID: <1447.1121761910@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@FreeBSD.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 08:31:52 -0000 In message <20050718183717.N9430@fledge.watson.org>, Robert Watson writes: > >This e-mail is about the second category -- device drivers which still run >with or require Giant. These in turn can be broken out into two >categories: > >- Device drivers that appear to have been modified to run MPSAFE, and are > possibly running partly Giant-free (i.e., perhaps the outbound path but > not interrupt handler, or vice versa). > >- Device drivers that haven't been touched and rely on Giant entirely. Can I add a little item to this project ? Some of the mii/phy drivers we have are specific to just one particular network driver. For instance I belive the brgphy.c is only ever used with the if_bge driver. These mii/phy drivers should be moved out of the miibus group and into the specific driver so that they only get put in the kernel if the driver is in the kernel. Currently, if a kernel is cut down to only a single driver for instance if_sis the brgphy.c driver is still compiled in because miibus pulls it in despite the fact that if_bge is not there. The practical change is the change sys/conf/files to compile the mii/phy driver files on the same option as the device driver, and to take the source files out of the miibus module kld and put them into the driver module. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 08:50:38 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACA916A41F; Tue, 19 Jul 2005 08:50:38 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9AF443D53; Tue, 19 Jul 2005 08:50:35 +0000 (GMT) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (unknown [192.168.48.2]) by haven.freebsd.dk (Postfix) with ESMTP id 58D48BC83; Tue, 19 Jul 2005 08:50:34 +0000 (UTC) To: Martin Nilsson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 19 Jul 2005 10:15:16 +0200." <42DCB694.7030007@gneto.com> Date: Tue, 19 Jul 2005 10:50:33 +0200 Message-ID: <1593.1121763033@phk.freebsd.dk> Sender: phk@phk.freebsd.dk Cc: arch@FreeBSD.org, Robert Watson Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 08:50:38 -0000 In message <42DCB694.7030007@gneto.com>, Martin Nilsson writes: >Robert Watson wrote: >> if_el Ethernet driver for 3Com Etherlink 3C501 devices. >> Mutxes present and exercised, not marked MPSAFE. > >This is an 8-bit ISA card that was a piss-poor-performer even when it >was new. Please don't waste developer resources on things like this! It was on the other hand one of the very first ethernet cards you could get your and on, and some of us still keep mementoes like that around :-) But I agree, that driver should just be EOL'ed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 09:22:26 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C264316A41C for ; Tue, 19 Jul 2005 09:22:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70BDC43D46 for ; Tue, 19 Jul 2005 09:22:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 0C2A546B9D; Tue, 19 Jul 2005 05:22:26 -0400 (EDT) Date: Tue, 19 Jul 2005 10:22:34 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <1593.1121763033@phk.freebsd.dk> Message-ID: <20050719100246.I15510@fledge.watson.org> References: <1593.1121763033@phk.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 09:22:26 -0000 On Tue, 19 Jul 2005, Poul-Henning Kamp wrote: > In message <42DCB694.7030007@gneto.com>, Martin Nilsson writes: >> Robert Watson wrote: >>> if_el Ethernet driver for 3Com Etherlink 3C501 devices. >>> Mutxes present and exercised, not marked MPSAFE. >> >> This is an 8-bit ISA card that was a piss-poor-performer even when it >> was new. Please don't waste developer resources on things like this! > > It was on the other hand one of the very first ethernet cards you could > get your and on, and some of us still keep mementoes like that around > :-) > > But I agree, that driver should just be EOL'ed. I think the right model is that we keep everyone updated on what drivers have been fixed, and which haven't, and at some point the list of unfixed drivers ceases to shrink. The remaining unfixed drivers become EOL'd. That way everyone who cares about a driver has lots of time to fix it. It's not all that hard to time-consuming to add a basic locking strategy to most network device drivers. Generally, it's a question of adding a sleep mutex to the driver softc, then holding that mutex around the majority of activity of the driver, dropping it when entering the network stack for the interface input routine or event calls (such as link changes). More sophisticated strategies are available, such as separately locking in-bound and out-bound paths if the hardware supports it (has separate receive and transmit units), serializing the driver in a thread around an event model, etc, but for most of the hardware we're talking about (10mbps ISA cards) there's not likely to be a big benefit to doing anything more than the most basic approach. Some known hard bits that depend on device driver: - Does the device driver have clean softc setup and tear-down paths? Most new drivers do, but some old drivers had quite different attach routines due to pccard support coming after ISA support, etc. Sometimes they don't have detach routines, or only have them for some busses. A simplification pass may be a good first step so that the locks are initialized and destroyed in central locations, etc. I believe Warner did a lot of this sort of thing for if_ed last year, which should help a lot when it comes to locking. - Does the driver have lots of special case code and handling for different variations on support hardware? if_dc and if_de are classic examples of this, where there is a large quantity of special case code, making it difficult to read, and difficult to test thoroughly. - Does the driver have lots of likely obsolete optimization and instrumentation? Early 100mbps cards, such as those support by if_de, required quite a bit of magic to achieve the performance they did on ISA busses. A lot of that magic is ifdef'd and not used by default. A simplification pass may be a good first step. If you have a bit of experience with network device drivers, and the hardware, it should take only a few hours to do a first pass at locking a driver in the list. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 15:20:00 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53F2016A41F; Tue, 19 Jul 2005 15:20:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC29F43D48; Tue, 19 Jul 2005 15:19:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6JFHdHV053007; Tue, 19 Jul 2005 09:17:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Jul 2005 09:17:39 -0600 (MDT) Message-Id: <20050719.091739.74697104.imp@bsdimp.com> To: martin@gneto.com From: Warner Losh In-Reply-To: <42DCB694.7030007@gneto.com> References: <20050718183717.N9430@fledge.watson.org> <42DCB694.7030007@gneto.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, rwatson@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 15:20:00 -0000 From: Martin Nilsson Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 Date: Tue, 19 Jul 2005 10:15:16 +0200 > Robert Watson wrote: > > if_el Ethernet driver for 3Com Etherlink 3C501 devices. > > Mutxes present and exercised, not marked MPSAFE. > > This is an 8-bit ISA card that was a piss-poor-performer even when it > was new. Please don't waste developer resources on things like this! Well, if someone has a bunch of these that they need to keep working, then we would welcome such a contribution. However, I'd put it far down on the list for someone that's just looking to do stuff. We have about 10 drivers in the tree that likely can be fixed by being deleted. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 15:23:08 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2A9C16A41F; Tue, 19 Jul 2005 15:23:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3891B43D4C; Tue, 19 Jul 2005 15:23:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6JFKi8n053020; Tue, 19 Jul 2005 09:20:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Jul 2005 09:20:44 -0600 (MDT) Message-Id: <20050719.092044.41685623.imp@bsdimp.com> To: phk@haven.freebsd.dk From: Warner Losh In-Reply-To: <1447.1121761910@phk.freebsd.dk> References: <20050718183717.N9430@fledge.watson.org> <1447.1121761910@phk.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, rwatson@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 15:23:08 -0000 > Some of the mii/phy drivers we have are specific to just one particular > network driver. I've been looking into listing the mii drivers to include in a given kernel. For the general case, we want to include them all. For specific cases, only a small subset are necessary. I don't think tying them to a specific driver is necessarily the right way to go, as old designs have a bad habit of reappearing in new when you least expect it. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 15:29:12 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B066016A41F; Tue, 19 Jul 2005 15:29:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5997643D45; Tue, 19 Jul 2005 15:29:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6JFS4kS053164; Tue, 19 Jul 2005 09:28:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Jul 2005 09:28:50 -0600 (MDT) Message-Id: <20050719.092850.11989358.imp@bsdimp.com> To: phk@haven.freebsd.dk From: "M. Warner Losh" In-Reply-To: <20050719.092044.41685623.imp@bsdimp.com> References: <20050718183717.N9430@fledge.watson.org> <1447.1121761910@phk.freebsd.dk> <20050719.092044.41685623.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, rwatson@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 15:29:12 -0000 In message: <20050719.092044.41685623.imp@bsdimp.com> Warner Losh writes: : > Some of the mii/phy drivers we have are specific to just one particular : > network driver. : : I've been looking into listing the mii drivers to include in a given : kernel. For the general case, we want to include them all. For : specific cases, only a small subset are necessary. I don't think : tying them to a specific driver is necessarily the right way to go, as : old designs have a bad habit of reappearing in new when you least : expect it. BTW, explicit lists are much easier now that we can have something like include mii.all in our config files. As for the modules, some thought and care is necessary there, but I'm working on a long term build evolution for modules that might make solving the mii problem easier. As I move through the prototyping stage, I'll be posting some test patches. You can watch the progress in p4. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jul 19 16:47:06 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE14216A420 for ; Tue, 19 Jul 2005 16:47:06 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7563443D45 for ; Tue, 19 Jul 2005 16:47:06 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j6JGjOSk054041 for ; Tue, 19 Jul 2005 10:45:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 19 Jul 2005 10:45:24 -0600 (MDT) Message-Id: <20050719.104524.41687111.imp@bsdimp.com> To: arch@freebsd.org From: Warner Losh X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: miibus diffs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 16:47:06 -0000 Here's what I had in mind when I replied to phk. This seems to work well. The included message doesn't have the conf/mii.all file, but that looks like # # All the PHy devices. If your NIC has a subset of these, you can refrain # from adding the include line in your config file and instead list # the individual devices you need for your setup. # # $FreeBSD$ # device acphy device amphy device bmtphy device brgphy device ciphy device dcphy device e1000phy device exphy device inphy device lxtphy device mlphy device nsgphy device nsphy device pnaphy device pnphy device qsphy device rgephy device rlphy device ruephy device tdkphy device tlphy device xmphy device miibus If we start moving the PHYs used by only one driver to their modules, this might save a small amount in the miibus.ko. However, those drivers will still need the entire miibus.ko file anyway. I'd rather we not premature submicro optimize the module builds for a while to give me a chance to succeed or fail on the module work I'm about to start on. Warner http://perforce.freebsd.org/chv.cgi?CH=80531 Change 80531 by imp@imp_harmony on 2005/07/19 16:38:59 Make it possible to subset the mii bus trivially. # Note: the mii module still has all the mii bus drivers in it # since it has no way of knowing what the right subsetting should # be. Future work on the module system to parse files* will # correct this shortcoming. Affected files ... .. //depot/user/imp/newcard/conf/files#232 edit .. //depot/user/imp/newcard/conf/mii.all#1 add .. //depot/user/imp/newcard/i386/conf/GENERIC#73 edit Differences ... ==== //depot/user/imp/newcard/conf/files#232 (text+ko) ==== @@ -638,33 +638,33 @@ dev/mcd/mcd_isa.c optional mcd isa nowerror dev/md/md.c optional md dev/mem/memdev.c optional mem -dev/mii/acphy.c optional miibus -dev/mii/amphy.c optional miibus -dev/mii/bmtphy.c optional miibus -dev/mii/brgphy.c optional miibus -dev/mii/ciphy.c optional miibus -dev/mii/dcphy.c optional miibus pci -dev/mii/e1000phy.c optional miibus -dev/mii/exphy.c optional miibus -dev/mii/inphy.c optional miibus -dev/mii/lxtphy.c optional miibus +dev/mii/acphy.c optional acphy +dev/mii/amphy.c optional amphy +dev/mii/bmtphy.c optional bmtphy +dev/mii/brgphy.c optional brgphy +dev/mii/ciphy.c optional ciphy +dev/mii/dcphy.c optional dcphy pci +dev/mii/e1000phy.c optional e1000phy +dev/mii/exphy.c optional exphy +dev/mii/inphy.c optional inphy +dev/mii/lxtphy.c optional lxtphy dev/mii/mii.c optional miibus dev/mii/mii_physubr.c optional miibus dev/mii/miibus_if.m optional miibus -dev/mii/mlphy.c optional miibus -dev/mii/nsgphy.c optional miibus -dev/mii/nsphy.c optional miibus -dev/mii/pnaphy.c optional miibus -dev/mii/pnphy.c optional miibus -dev/mii/qsphy.c optional miibus -dev/mii/rgephy.c optional miibus -dev/mii/rlphy.c optional miibus -dev/mii/ruephy.c optional miibus -dev/mii/tdkphy.c optional miibus -dev/mii/tlphy.c optional miibus +dev/mii/mlphy.c optional mlphy +dev/mii/nsgphy.c optional nsgphy +dev/mii/nsphy.c optional nsphy +dev/mii/pnaphy.c optional pnaphy +dev/mii/pnphy.c optional pnphy +dev/mii/qsphy.c optional qsphy +dev/mii/rgephy.c optional rgephy +dev/mii/rlphy.c optional rlphy +dev/mii/ruephy.c optional ruephy +dev/mii/tdkphy.c optional tdkphy +dev/mii/tlphy.c optional tlphy dev/mii/ukphy.c optional miibus dev/mii/ukphy_subr.c optional miibus -dev/mii/xmphy.c optional miibus +dev/mii/xmphy.c optional xmphy dev/mk48txx/mk48txx.c optional mk48txx dev/mlx/mlx.c optional mlx dev/mlx/mlx_disk.c optional mlx ==== //depot/user/imp/newcard/i386/conf/GENERIC#73 (text+ko) ==== @@ -203,8 +203,9 @@ device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. -# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! -device miibus # MII bus support +# NOTE: Be sure to keep the 'include mii.all' line in order to use these NICs! +# NOTE: When subsetting, make sure you get the phy your nics need! +include "mii.all" device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes @@ -229,7 +230,7 @@ # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC -# 'device ed' requires 'device miibus' +# 'device ed' requires 'include mii.all' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards From owner-freebsd-arch@FreeBSD.ORG Wed Jul 20 09:34:47 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BED4716A41F; Wed, 20 Jul 2005 09:34:47 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1191443D49; Wed, 20 Jul 2005 09:34:46 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd25.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DvAyS-00050c-04; Wed, 20 Jul 2005 11:34:44 +0200 Received: from Andro-Beta.Leidinger.net (bVyUSEZeYeTpLkowwOc6VEL47rRQiLLMFT0H24ZmAxcBzVr-M6XRsz@[84.165.229.68]) by fwd25.sul.t-online.de with esmtp id 1DvAyD-0wgZ8q0; Wed, 20 Jul 2005 11:34:29 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j6K9YPIv029081; Wed, 20 Jul 2005 11:34:25 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.31 ([141.113.101.31]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Wed, 20 Jul 2005 11:34:24 +0200 Message-ID: <20050720113424.x4h21d1j40gggk0o@netchild.homeip.net> X-Priority: 3 (Normal) Date: Wed, 20 Jul 2005 11:34:24 +0200 From: Alexander Leidinger To: Robert Watson References: <20050718183717.N9430@fledge.watson.org> <42DC08A4.2060001@samsco.org> <20050718235043.Y15510@fledge.watson.org> In-Reply-To: <20050718235043.Y15510@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: bVyUSEZeYeTpLkowwOc6VEL47rRQiLLMFT0H24ZmAxcBzVr-M6XRsz@t-dialin.net X-TOI-MSGID: 7a84365d-13b7-40c3-98cc-b7e5fefbea35 Cc: arch@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 09:34:47 -0000 Robert Watson wrote: >> 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. I4B forces mpsafenet=0 (or how it is spelled... I'm not at a machine where I can look it up). I assume you're talking about the functionality you can modify with this sysctl... Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 He who knows that enough is enough will always have enough. -- Lao Tsu From owner-freebsd-arch@FreeBSD.ORG Fri Jul 22 02:15:43 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C08EB16A446 for ; Fri, 22 Jul 2005 02:15:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 085E943DA3 for ; Fri, 22 Jul 2005 02:15:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6AB6A46B28; Thu, 21 Jul 2005 22:15:27 -0400 (EDT) Date: Fri, 22 Jul 2005 03:15:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20050720113424.x4h21d1j40gggk0o@netchild.homeip.net> Message-ID: <20050722031435.Y16902@fledge.watson.org> References: <20050718183717.N9430@fledge.watson.org> <42DC08A4.2060001@samsco.org> <20050718235043.Y15510@fledge.watson.org> <20050720113424.x4h21d1j40gggk0o@netchild.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 02:15:44 -0000 On Wed, 20 Jul 2005, Alexander Leidinger wrote: > I4B forces mpsafenet=0 (or how it is spelled... I'm not at a machine > where I can look it up). I assume you're talking about the functionality > you can modify with this sysctl... Indeed -- three major subsystems are of specific concern right now: - i4bsd - tty - usb Poul-Henning has expressed some interest in the tty code, and hopefully will do something about it sometime soon. I'm happy to deal with if_slip and likely if_ppp once the tty code is done. The various Cronys drivers are all waiting on the tty code, but otherwise appear ready. Robert N M Watson