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

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2010-11-12 19:07, Thor Lancelot Simon wrote:
> 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.

Hum. The subject was rwlock, mutex and lock. Operastions that have been 
well known and understood since the 60s.
And I think that it wasn't AD at all who wrote the innermost part of 
this quote. It was pooka.

> 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 sidetracking the issue being discussed by throwing fud at it! 
Stop that.

> 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.

I do advocate that MI code should make fewer assumptions about the 
hardware, yes. I doubt I could ever manage to figure out a way to use 
INSQUE/REMQUE, since they are way to specialized to be possible to match 
agains any abstract interface we might come up with, unless we actually 
decide to have doubly linked lists as a MI concept.

However, things like locks and mutexes are more or less very primitive 
concepts, which we already provide as services done by the MD code. I 
was just questioning how the split between MI and MD pieces had been 
made, since it obviously made a sensible, efficient implementation on a 
VAX such a headache, while a VAX obviosuly easily can implement both 
locks, rwlocks and mutexes more or less directly mapped to primitive 
instructions.

That suggest to me that the current abstraction have failed.

I'm sorry if it is only me who see it that way.

> 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.

I agree with most of that comment. The thing I disagree with is the 
claim that a thing like a lock or a mutex can't be implemented 
efficiently on an "old" machine. NetBSD does not really support any 
machine old enough to have been around before these concepts were well 
known, understood, and architectures were designed with the explicit 
thought of making these operations efficient.

> 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.

Well. My wish were simple. It somehow turned into a centithread in no time.

I just wanted a mutex and a lock interface which I could inline, and 
which only had the idea that I wanted to take or release a mutex or a 
lock. Some additional functions, like upgrading and downgrading rwlocks 
is also perfectly fine, as well as just trying to take locks, and to be 
able to query the lock/mutex for various information.

For some reason, this wish is apparently an horrible idea to most people 
around here. For that I can only say that I'm sorry for you.

> > 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.

Who did I lambast?
And I willingly admit to not understanding enough of gcc to fix it when 
there have been problems, but I do atleast have one gcc bug for VAX 
fixed that I can take responsibility for, so it is not as if I have not 
tried to contribute as well as I can (and I have done a bunch of other 
stuff for the VAX port over the years as well, even if I have seldom 
been very visible.

And dammit! Why do people take so much personal offense when I criticize 
a design decision which I thought would be obvious that it could use 
some improvement?

> 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.

There are many ways care, or the lack of, can be expressed.
Unneccesary bias in what I assume should be a MI implementation, which 
really isn't, is one. Having code that compiles, but which in reality is 
not useful on a platform is another.
It is not that I think people are explicitly out to ruin some ports, 
it's just that some people seem to prefer to do a simpler solution than 
ideal, since the simpler solution goes directly towards the target they 
play on, and let others suffer though neglect.

I feel the subject of locks and mutexes are pretty much in that area. 
But people are of course free to disagree.
But as I said before. Implementing a mutex on a VAX, is really simple. 
Doing it in the NetBSD framework is not. Why is that? The only answer I 
can come up with is that the MI/MD split was made in a bad way.

Don't come here blaming old technology, new advances, modern computer 
theory, and all kind of smoke for this. We are still talking about locks 
and mutexes, and there are absolutely no problems in implementing them 
on a VAX. There is, however, headaches implementing CAS. But CAS is not 
a lock, or a mutex.

> 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.

I'm trying very hard not to yell, but to try and give reasonable 
arguments, and point at reasonable ideas. But responses like this does 
not help.

> 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.

I very much appreciate all the work that do go in to getting things to 
work better. And a lot of it is really good (or else I would have left a 
long time ago).
But getting yelled at for trying to suggest that there are problems, and 
that some things could perhaps be done in another way, that I believe 
all would benefit from, is not really fruitful, nor a good way to keep 
support in the long run from people who are trying to contribute.

Just to be clear - I'm still not in any way saying that machines using 
CAS today should stop using it. What I was asking for was just a 
smoother way for machines that don't have CAS to have a way to implement 
the services used in other ways that would make more sense on those 
machines, while still providing the same end result.
That is not possible today, and that is, I think, the sign of a bad MI 
abstraction. And on a machine like a really old VAX, that really hurts 
performance.

Remember, I'm playing with a VAX 8650 here. That machine was introduced 
in 1986, and the 8600 was introduced in 1984. We are talking about 
around 25 year old machines here. They are not as fast, and bad designs 
in software quickly comes back to bite you.

However, running VMS or Ultrix on the machine, it feels snappy. There is 
no real reason why NetBSD should be so much slower. And it didn't use to 
be. I've been running NetBSD on that machine since around 1.2 or so... 
(Started with an 11/750 and version 0.9 in fact...)

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol