HEADS UP: IPX over IP support removed
Bruce M. Simpson
bms at FreeBSD.org
Wed Jun 13 14:30:33 UTC 2007
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.
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)
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
The incentive for using ATM as a cross connect isn't really there.
FreeBSD is not going to displace dedicated ATM concentrators from
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
> 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.
More information about the freebsd-current