Date: Wed, 13 Jun 2007 16:17:27 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: HEADS UP: IPX over IP support removed Message-ID: <20070613161435.G83504@fledge.watson.org> In-Reply-To: <466FFF86.5000401@FreeBSD.org> References: <20070613150534.D83504@fledge.watson.org> <466FFF86.5000401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Jun 2007, Bruce M. Simpson wrote: > Thanks for your work on removal of IPX-in-IP. Just to recount a few things > regarding the use of Giant in the network code and add my 2c. > > The use of Giant for interfaces has caused some complication in getting the > locking right during my passes over the Layer 2 network code and IPv4 code. > This continues to be the case. > > It also has the potential to make merging IGMPv3/MLDv2 more difficult than > it has to be. So I'd be very glad to see NET_NEEDS_GIANT get axed in the 7.x > train if that's at all possible. It has to go, it's a blocker. Unfortunately, removing NET_NEEDS_GIANT only removes the protocol Giant compat shims, not the network interface ones (IFF_NEEDSGIANT). Due to the large number of remaining interfaces, I was unable to remove it (as I had hoped) for the 7.0 release. The main problem with IFF_NEEDSGIANT is the synchronous aquisition requirement for ioctl, which is not fixable. Hopefully in 8.0 we will be able to drop support for non-MPSAFE network device drivers. I agree entirely that these compat shims have been causing a lot of nastiness in the network stack -- in my draft de-NET_NEEDS_GIANT patch, almost 300 lines of compatibility wrapper code are removed from the kernel sources, substantially simplifying the socket code. Robert N M Watson Computer Laboratory University of Cambridge > > Robert Watson wrote: >> >> The following subsystems remain with NET_NEEDS_GIANT dependence: >> >> i4b - ISDN framework, for which there is on-going work > > I don't use ISDN. I suspect Deutsche Telekom's wider rollout of T-DSL has > nibbled away at the incentive to use this. There are however still good > reasons to use ISDN; its symmetric bandwidth in particular makes it a > favorite for sound engineers doing outside broadcast. >> >> netatm - One of three ATM frameworks, for which there is on-going work > > I believe it is reasonable to call time on netatm (Host ATM Research > Platform, HARP), though I haven't heard recently from the guy I donated > hardware to in order to work on this. > > Most of what it does can be done with Netgraph and the NATM (Native ATM) > layer. > > For host xDSL connectivity where ATM is specified as a transport folks are > going to want to use PPPoA anyway as it's specified by the ITU for > G.DMT-Lite. FreeBSD can do this: use userland ppp, netnatm, and a device with > an ATM25-to-G.DMT modem such as the Alcatel Speedtouch or other supported > ATM25 cards. This is more of interest to folks building consumer/home > routers. > > The incentive for using ATM as a cross connect isn't really there. FreeBSD is > not going to displace dedicated ATM concentrators from established players. > > In the long term FreeBSD should probably focus on supporting Metro Ethernet > as it is going to be more useful. Andrew Thompson's excellent work on if_lagg > moves us towards this goal. > >> >> ng_h4 - Bluetooth serial drivers -- I know of no on-going work here > > I don't have figures, but in my experience the vast majority of commodity > silicon out there for Bluetooth is USB based. H4 exists to support attachment > of Bluetooth via asynchronous serial ports. > > It seems reasonable that the h4 drivers are disconnected from the main build; > if someone needs them e.g. for an embedded application then it seems > reasonable that they fix the locking while they're there. >> >> IPSEC - KAME IPSEC implementation, which will be removed and replaced with >> FAST_IPSEC in 7.0, once IPv6 support is committed for it. > > I'm 100% behind George on this as an architectural decision, although I am > not using IPSEC for anything these days. > >> >> Of the above, I am concerned about ng_h4 since I've heard nothing about >> potential work on this. I believe the dependence issue has to do with >> entering the non-MPSAFE TTY code without Giant, and perhaps this is easily >> addressed... > > See above. I think it's essential we push forward with the removal of Giant > from the network stack entirely based on my experience porting the SSM socket > layer. > > Kind regards > BMS >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070613161435.G83504>