HEADS UP: IPX over IP support removed
Robert Watson
rwatson at FreeBSD.org
Wed Jun 13 15:17:29 UTC 2007
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
>
More information about the freebsd-current
mailing list