Date: Wed, 15 Mar 2006 10:54:40 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: netatm: plan for removal unless an active maintainer is found Message-ID: <20060315105031.E5861@fledge.watson.org> In-Reply-To: <20060314.204252.74651890.imp@bsdimp.com> References: <20060315004530.B5861@fledge.watson.org> <20060314.204252.74651890.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Mar 2006, Warner Losh wrote: >> The main motivator for pruning has to do with the SMP network stack work: >> we're reaching the point, discussed on a number of occasions previously on >> this mailing list, where jettisoning unmaintained network stack components >> that are unable to run MPSAFE, is highly desirable. > > What's the timeline for non-MPSAFE network drivers to be taken out > behind the woodshed? Right now the list appears to be: > > an, awi, cm, cnw, cs, en, ex, fatm, ie, lnc, patm, fea, fpa, > mn, ray, sbni, sbsh, snc, tx, wl, xe, ar, sr, plip > > Of those, an, awi, cnw, cs, ex, ray, snc, and xe have PC Card attachments, > so I may wind up doing at least some of them (snc is pc98 only, cnw and ray > are very obsolete wireless cards, so I don't think I'll do them). The other large chunk of non-MPSAFE network device driver and stack code, FYI, is the i4b code. In principle, a newly added committed is now available to work on the capi integration, and hopefully will do the SMP safety work as part of that. If not, it's also on the chopping block. It's a significant piece of otherwise unmaintained code, and something that's not trivially testable (at least, not by me or anyone I've talked to lately :-). I don't want to see it leave the tree, but it needs to be updated so that it can run MPSAFE before 7.0. Otherwise, with the exception of KAME IPSEC, the network stack code is actually in pretty good shape for removing the Giant compat shims. We've had at least a couple of people say they're willing to work on this and take steps in the right direction (including some initial patches for IPSEC improvement), but I guess we'll see come August whether it has happened. The discussion has always been about whether it's better to add IPv6 support to FAST_IPSEC, or lock down KAME IPSEC. Both are desirable, and both require significant familiarity with the code and protocols involved. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060315105031.E5861>