netatm: plan for removal unless an active maintainer is found
M. Warner Losh
imp at bsdimp.com
Wed Mar 15 18:06:41 UTC 2006
In message: <20060315185803.1956114c at Magellan.Leidinger.net>
Alexander Leidinger <Alexander at Leidinger.net> writes:
: Am Wed, 15 Mar 2006 10:29:03 -0700 (MST)
: schrieb "M. Warner Losh" <imp at bsdimp.com>:
:
: > : > 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.
: > :
: > : I may add, that Hans-Petter Selasky has a MPSAFE replacement (written from
: > : scratch it seems) for I4B (AFAIK including capi) and the USB stack. I have
: > : tested or reviewed neither of them, but as far as I can read in the
: > : mailinglists, he adresses not only the issues you mention here, but he also
: > : provides bugfixes and additional features compared to our current code base.
: >
: > The problem is that this code isn't busdma safe at the moment. It was
: > posted for review on the NetBSD lists and this was the biggest set of
: > comments on tech-kern at netbsd.org. Since it isn't busdma safe, we'd
: > lose usb on sparc64 (and maybe arm) when this code is brought into the
: > tree. There have also been signficant concerns about the locking
: > that's done in the code as well, but I've not reviewed it recently.
: >
: > There's been a lot of work done here, and that work is generally good,
: > but last time I looked at the code it wasn't ready to be integrated to
: > the tree.
:
: The questions are:
: - What's less work to do?
: - Is there someone who is willing to do the work?
Agreed. Hans-Petter's work has great potential, but I think someone
with a lot of time and knowledge of FreeBSD specific issues is going
to need to work with him to properly integrate it into the tree. It
isn't a drop in right now, but could be with some work.
If usb abd usbHPS can co-exist in the tree, we might be able to do
some of this in-tree. But usb is a very important subsystem and
transitioning to a new code base is a high-risk thing.
Warner
More information about the freebsd-arch
mailing list