Re: HEADS UP: IPX over IP support removed
- From: Robert Watson <rwatson@xxxxxxxxxxx>
- Date: Wed, 13 Jun 2007 16:17:27 +0100 (BST)
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
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- References:
- HEADS UP: IPX over IP support removed
- From: Robert Watson
- Re: HEADS UP: IPX over IP support removed
- From: Bruce M. Simpson
- HEADS UP: IPX over IP support removed
- Prev by Date: Re: HEADS UP: IPX over IP support removed
- Next by Date: Re: HEADS UP: IPX over IP support removed
- Previous by thread: Re: HEADS UP: IPX over IP support removed
- Next by thread: Re: HEADS UP: IPX over IP support removed
- Index(es):
Relevant Pages
|
|
