On 30 May, 2015, at 16:09 , David Holland <dholland-t...@netbsd.org> wrote: > In these cases, keeping the extra old stuff along with its > complications during the framework rototilling usually results in a > better framework; but it makes the rototilling cost a lot more. As the > amount of manpower available has been dropping and the urgency of > certain reconstruction projects (most notably, the multiprocessor > network stack) only increases, there's a point where it becomes a > choice: keep the old stuff, or do the reconstruction. I don't know if > we've actually hit that point yet with the arcnet code or not; > probably not, actually. But unless something changes, we'll get there > soon enough. And then the choice comes right down to the point at > issue: keep the old stuff, which has assorted benefits and enables > continuing use of the old hardware it's associated with, or do the > reconstruction, which is necessary to remain a credible platform for > production use on modern hardware.
It's too long an argument, but I think any approach to a multiprocessor network stack that attempts to get there starting with the existing network L2/L3/interface code as a base is likely not on the table. I would offer the rather herculean effort spent on FreeBSD to attempt to do exactly that, and the fairly mediocre result it produced, as evidence. The resources to match that probably don't exist, and if there were a better, easier way to do this it would have been done already. I think the least cost way to produce a better result is actually to make a big change, preserving the device drivers and the transport protocol code (which needs to run single-threaded per-socket in any case) and any non-IP protocol code that still works (running single-threaded) but doing a wholesale replacement of the code that moves packets between those things with something that can operate without locks. Doing it this way has some risks, not the least of which is that it would leave you with networking code unlike anyone else's (though if it were well done I'm not sure this would last, everyone has trouble with the network stack), but I think this makes the problem tractable and has a good chance of producing something that scales quite well even without a lot of Linux-style micro-optimization effort. I also believe that you get a better, more complete result, if the network stack is well structured to make good use of a variety of interface hardware and makes supporting that variety as easy as possible, despite the fact that for a truly "modern" network stack very little other than Ethernet matters any more. For this reason I think ARCNET support (I'll bet token ring will come up at some point too, it has its own complexities) should stay. The thing is, though, that the requirement for continued support for ARCNET (or anything else) has got to be, more or less, a machine or two with ARCNET cards capable of running NetBSD, a not-NetBSD machine with an ARCNET card to talk to and a network to connect them. It isn't really possible to support anything without some way of running it to test it. Asking for ARCNET support in the absence of hardware to test on, however, is really asking for something quite different. Since you can't make more than small, mechanical changes to anything and expect it to work without testing (and I'm not even sure about the small, mechanical changes) what is being asked instead is that nothing be done that requires changes to the ARCNET code on the disk right now, nor the framework it relies on to operate, while making it someone else's problem to figure out how to deal with that constraint. This isn't fair, and I don't think it has any possibility of working. No one wants to break anything, but a consequence of changing code is that code will have to change. If the ARCNET code is in the bit that must change, and I believe it is, either there must be a way to test those changes or it must be discarded. If this can't be lived with then ARCNET-with-no-hardware-to-run-it-on is just a sideline issue and you should instead be asking yourself (seriously) the more fundamental question of whether you really want the networking code to change at all or are in fact happy with it just the way it is now, since the latter is a whole lot less work for everyone involved. So if you really want ARCNET or token ring to continue to be supported I think the best thing one could do to ensure that, and do everyone else a favour too, is to assemble the hardware required to test it while the hardware still exists. A plausible test harness might also work, though if there is no hardware to run it on I'm not sure I see the point. If this is too much effort but you still feel it must stay then maybe the best course is to minimize everyone's effort. Dennis Ferguson