HEADS UP: IPX over IP support removed

[Bruce M. Simpson]

Hello Robert,

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) 
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