Re: Removing ARCNET stuffs

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 30 May, 2015, at 16:09 , David Holland <dholland-tech%netbsd.org@localhost> 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