Re: HEADS UP: IPX over IP support removed

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
>