[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Please do not yell at people for trying to help you.
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!
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
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
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
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
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
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
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 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
Main Index |
Thread Index |