Please do not yell at people for trying to help you.

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, Nov 12, 2010 at 07:05:34PM +0200, Antti Kantee wrote:
> On Fri Nov 12 2010 at 15:25:04 +0100, Johnny Billquist wrote:
> > >Freeway design is not driven by the requirements of the horse.  If a horse
> > >occasionally wants to gallop down a freeway, we're happy to let it as long
> > >as it doesn't cause any impediment to the actual users of the freeway.
> > >
> > >Over 15 years ago NetBSD had a possibility to take everyone into account
> > >since everyone was more or less on the same line.  This is no longer true.
> > >If old architectures can continue to be supported, awesome, but they may
> > >in no way dictate MI design decisions which hold back the capabilities
> > >of modern day architectures.
> > 
> > So what you are arguing is that MI needn't be so much MI anymore, and 
> > that supporting anything more than mainstream today is more to be 
> > considered a lucky accident than a desired goal?

No, Andrew didn't say that.  On the other hand, he did point out that it
may not be possible to provide *efficient* machine-independent abstractions
to perform operations that were exotic, uncommmon, or simply unheard of
when very old architectures were designed.

Why is this surprising?  Hardware design progresses, and it's silly to
think that the only type of advances that will occur will be the type
that can be efficiently emulated by some older functionality.  Ought we
simply not use new hardware features?

You are ultimately asking for *more* machine-dependent code in NetBSD,
not less -- since, for example, you want to use insque/remque, which would
make all sorts of currently MI datastructures MD.

The basic problem with VAX, and a few other old or unusual architectures,
is that they cannot efficiently implement certain MI abstractions that are
well suited to most architectures we support.  Causing there to be less MI
code, and more MD code, in the tree in order to accomodate that is not a
good idea.

Now you're going to say "pick better MI abstractions".  Guess what?  Those
do not always exist.  No matter how much one might wish they did.

> You can try to twist my words in any way that pleases you.  However, the
> fact is that people who put forward a heroic effort in modernizing NetBSD
> will not be held accountable for making sure prehistoric architectures
> keep up (*).  Some of our older ports have active supporters who keep
> the port up to speed with MI changes, set up emulator support, publish
> test run results etc.  These ports will continue to be supported by
> NetBSD indefinitely.

What Antti said.  And, further, I would like to point out that you (Johnny)
didn't step forward and resuscitate VAX support in GCC -- one of the same
NetBSD developers you're lambasting for not caring enough about whether
old architectures work did so.  After the GCC project itself simply abandoned
VAX support.  Another NetBSD developer brought PCC back to life, so you even
have a choice of compilers!  A *huge* amount of work goes into keeping
old hardware working in NetBSD.  You may not like the best-we-can-do results,
but it is profoundly rude to attack us for trying.

The claim that NetBSD only cares about x86 is even more absurd.  NetBSD
supports a huge array of architectures, usually in both their modern and
ancient implementations.  We'll run on everything from R2000 to the newest
multicore 64-bit MIPS processors; a similar range of support exists for
ARM, powerpc, and many other processor and system families.  We have not
done as good a job keeping up with SPARC or the death-rattle models of 68k
but we certainly haven't ripped SPARC or 68k support out either -- nor does
anyone intend to do so.

What *is* the case is that when one chooses datastructures and algorithms
suited to *most processors currently available* or even *most processors
ever supported by NetBSD, in terms of installed systems and possibly at all*,
some older architectures suffer worse than others.  You keep dodging the
question of whether it would somehow be better to make most NetBSD users
suffer rather than a few, generally by suggesting NetBSD developers have
a responsibility to magically ensure nobody suffers.

There is no magic.  Get used to it.  A lot of hard work has gone into
minimizing this kind of suffering, and it's work nobody is being paid to
do, either.  Please do not yell at the people doing that work.

It is likely the case that an older version of NetBSD with *less* MI
abstractions in the areas of bus access, memory management, synchronization,
etc. would be better suited to your needs.  Some people here have perhaps
been less than gentle in telling you so.  I'm sorry about that.  But,
nonetheless, please do not yell at us for doing the best we can to keep
modern NetBSD working for you at all.

Thor