tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mutexes, locks and so on...

On 2010-11-12 17:48, Jonathan Perkin wrote:
* On 2010-11-12 at 16:26 GMT, Johnny Billquist wrote:

What? That NetBSD no longer supports most of the architectures it used to?

Unless you've redefined the meaning of 'most' I think that's a pretty
wild and inaccurate claim.

Please try and keep more context when you quote...

The full text was:

>> bqt, wanna start a fork?  Looks as though NetBSD no longer supports
>> most of the architectures it used to.
> That idea could have merit.

What? That NetBSD no longer supports most of the architectures it used to?

With der Mouse making the initial comment, and AD replying that the idea could have merit, and then me asking if ADs comment was at the "no longer..." part.

I was not making a statement, but a question in response to what someone else said, which was ambiguous. (Just because I choose one interpretation does not mean I claim that things actually are that way.)

Maybe it's time to change the "of course it runs NetBSD" to "is it
an x86? Then it also runs NetBSD in addition to Linux, FreeBSD and
OpenBSD, not to forget Solaris and Windows".

Why do you and mouse have this insatiable appetite to focus on x86?  Seems
quite disrespectful to the many people who continue to improve and add
support for platforms to NetBSD which aren't x86-based.

Because it would seem that such support come in spite of, and not because of, some decisions made? :-)

Personally I think there is huge merit to having an off-shoot of an older
NetBSD which can still be developed for older systems like VAX, and have
advocated for this in the past.

After all, are you really interested in the features NetBSD is adding over
time?  Which parts of -current are you dying to run on the VAX which makes
you angry at the suggestion of dropping support for it?  Lua?  Rump?  NPF?
ATF?  Modules?  My guess, actually, is that the vast majority of new code
going into NetBSD is things you would advocate against anyway as they do
not make sense for your architecture.

Honestly, I don't know if I'm interested in all the new stuff myself, but others might be, and me trying to get the VAX to work better might benefit someone who do care.
And I like hacking around at things.

Create a fork (forks are good!), rip out all this bloat we've been adding
for the past N years, merge in bits you do like, and concentrate on
keeping things small, fast, and suited for your systems.  Everyone wins.

You might be right about that. Or atleast the ones that don't win will be a group that I no longer care about.

However these discussions always end up with wild accusations (e.g. your
'no longer supports most' statement above) and go nowhere.  It would be
nice if someone would prove me wrong this time.

Can't prove you wrong.
All I asked for (and which started this thread) was if we couldn't make the interface for mutex and locks a little better, by not assuming that every architecture have CAS. After all, the operations on locks and mutexes are pretty well understood and simple, and does not actually involve the word CAS. So I found it unfortunate that the design we have today basically force all architectures to implement and use CAS none the less.

That seems (to me) to be a design with the split between MI and MD made at the wrong place. I was trying to find out if there was some other good reason for this, such as some twisted detail behind the curtains that actually required the CAS semantics, but I haven't heard anything like that. Instead I have only heard that everyone nowadays have CAS, so it is ok to write code that expects CAS to exist, and I'm just whining, and god knows what else have turned up in this thread.



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

Home | Main Index | Thread Index | Old Index