On Fri, Nov 12, 2010 at 11:09:20AM +, Andrew Doran wrote:
On Thu, Nov 11, 2010 at 05:22:03PM +0100, Johnny Billquist wrote:
The mutex implementation in place now, is nice in many ways, as it
is rather open to different implementations based on what the
hardware can do. However, I
On Fri, Nov 12, 2010 at 11:09:20AM +, Andrew Doran wrote:
It was deliberate. rwlocks are only effective in situations where the
codepath is heavyweight. So I felt while it is worthwhile optimising them
if possible, an all out jihad is just not warranted (as it might be for
mutexes). So
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But it would be nice if we could leave it possible
to do things in different
On Fri, Nov 12, 2010 at 01:56:20PM +0100, Joerg Sonnenberger wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But
On 11/12/10 03:58, David Holland wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
[spl mutex stuff]
Hum? So that was introduced with the new locking code then? Because
back when we used splraise/splx, the above would not have worked.
This would have
On 11/12/10 12:16, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 11:09:20AM +, Andrew Doran wrote:
It was deliberate. rwlocks are only effective in situations where the
codepath is heavyweight. So I felt while it is worthwhile optimising them
if possible, an all out jihad is just not
On 11/12/10 13:56, Joerg Sonnenberger wrote:
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
Hmm. Hard to argue about this. While I think it's nice if we try to
keep the kernel agnostic, the user api is not something I'm arguing
about changing. But it would be nice if we could
On 11/12/10 15:00, Johnny Billquist wrote:
On 11/12/10 14:55, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 02:35:59PM +0100, Johnny Billquist wrote:
Augh! And in which way would that improve things? Restarting
operations, as well as checking if they should be restarted will
hardly be
On Fri, Nov 12, 2010 at 02:58:16PM +0100, Johnny Billquist wrote:
lock(interlock)
lock(a)
lock(b)
unlock(interlock)
I realized I'm getting sloppy here. When I say locks in this
context, I'm actually talking about spin mutexes. Simple locks are a
different story, since they don't fool with
On 11/12/10 15:07, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 02:58:16PM +0100, Johnny Billquist wrote:
lock(interlock)
lock(a)
lock(b)
unlock(interlock)
I realized I'm getting sloppy here. When I say locks in this
context, I'm actually talking about spin mutexes. Simple locks are a
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in the past, I believe NetBSD have tried to raise above such simple and
naïve
On 11/12/10 15:22, Antti Kantee wrote:
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in the past, I believe NetBSD have tried to raise
On Fri, Nov 12, 2010 at 03:25:04PM +0100, Johnny Billquist wrote:
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?
It is not about mainstream. Please tell me
On Fri, Nov 12, 2010 at 02:30:58PM +0100, Johnny Billquist wrote:
Hmm. The thing with rwlocks though is that the actual concept is
just that you have locks that you want to grab, with the expanded
idea that you can have them at two different levels. read or write.
There is nothing inherently
It is not about mainstream. Please tell me one architecture that has
been created in the last 10 years, supports at least 32bit address
space, virtual memory and doesn't support either CAS or LL/SC.
What's that got to do with it?
NetBSD used to be about proper separation between MI and MD so
On Fri, Nov 12, 2010 at 09:50:52AM -0500, der Mouse wrote:
Over 15 years ago NetBSD had a possibility to take everyone into
account [...]
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
On 11/12/10 15:52, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 02:30:58PM +0100, Johnny Billquist wrote:
Hmm. The thing with rwlocks though is that the actual concept is
just that you have locks that you want to grab, with the expanded
idea that you can have them at two different levels. read
On Nov 12, 2010, at 6:39 AM, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 03:25:04PM +0100, Johnny Billquist wrote:
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
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That
will surely help. Please remind me again, why would people in general
want to run NetBSD instead of Linux or FreeBSD?
It's good thing to keep support for old machines with MI API.
It's bad thing to complain about
On Sat, 13 Nov 2010, Izumi Tsutsui wrote:
Oh well! I guess I should go away now.
And me, and everyone else running anything but x86_64 (and, maybe,
i386; I don't know whether that's sufficiently modern to count).
Yes, please go.
Wow. I guess you can add me to the list of people leaving.
On 11/12/10 16:38, Izumi Tsutsui wrote:
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That
will surely help. Please remind me again, why would people in general
want to run NetBSD instead of Linux or FreeBSD?
It's good thing to keep support for old machines with MI API.
On 11/12/10 15:56, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 09:50:52AM -0500, der Mouse wrote:
Over 15 years ago NetBSD had a possibility to take everyone into
account [...]
So what you are arguing is that MI needn't be so much MI anymore, and
that supporting anything more than mainstream
Andrew Doran a...@homeworld.netbsd.org wrote:
bqt, wanna start a fork? Looks as though NetBSD no longer supports
most of the architectures it used to.
That idea could have merit.
Indeed..
--
Mindaugas
On 11/12/10 16:12, Izumi Tsutsui wrote:
Oh well! I guess I should go away now.
And me, and everyone else running anything but x86_64 (and, maybe,
i386; I don't know whether that's sufficiently modern to count).
Yes, please go.
Ooo. Really friendly here. Yes, excellent idea. Drive people
On 11/12/10 16:23, Izumi Tsutsui wrote:
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That
will surely help. Please remind me again, why would people in general
want to run NetBSD instead of Linux or FreeBSD?
It's good thing to keep support for old machines with MI API.
* 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.
Maybe it's time to change the of course it runs NetBSD to is it
an
On Nov 12, 2010, at 7:08 AM, Johnny Billquist wrote:
On 11/12/10 15:56, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 09:50:52AM -0500, der Mouse wrote:
Over 15 years ago NetBSD had a possibility to take everyone into
account [...]
So what you are arguing is that MI needn't be so much MI
Antti Kantee po...@cs.hut.fi wrote:
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in the past, I believe NetBSD have tried to raise
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
I was thinking of how AVR32 implements LL/SC sematics and wondering
if I apply the same ideas to the VAX.
Basically, everytime AVR32 takes an exception it clears a flag which
was set by the load-locked instruction. Store-conditional sees the
flag was cleared and fails the store.
Instead of a
Exactly! And I would like to emphasize that this has nothing to do
with breaking of MI and MD abstraction or x86-centric view.
Yes, I imagine you would. But it's still false.
Decision was to provide CAS abstraction [sic!] as a primitive for MI,
by the MD land - in a same way, like we have
On Fri Nov 12 2010 at 16:58:18 +, Mindaugas Rasiukevicius wrote:
What Johnny apparently suggests is to revisit mutex(9) interface, which
is known to work very well, and optimise it for VAX. Well, I hope we
do not design MI code to be focused on VAX. If we do, then perhaps I
picked the
On Nov 12, 2010, at 9:24 AM, David Young wrote:
On Thu, Nov 11, 2010 at 05:22:03PM +0100, Johnny Billquist wrote:
*snip snip*
All others rely on the __HAVE_SIMPLE_MUTEXES
implementation, which utilize a CAS function. Obviously the VAX does
not have a CAS, and it is rather costly to simulate
Yes. NetBSD is the only option for some of us (non-new processors) and
now you're trying to make it rotten for us.
It's a choice which we should focus on. No perfect world.
Wouldn't it make more sense with your limited resources to contribute to
something more mainstream-focused like
der Mouse mo...@rodents-montreal.org wrote:
Decision was to provide CAS abstraction [sic!] as a primitive for MI,
by the MD land - in a same way, like we have copy(9), fetch(9),
store(9) or many other means, just in this case MI asks MD to ensure
atomicity. It was relevant to make a
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
On Fri, 12 Nov 2010, Thor Lancelot Simon wrote:
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
On Nov 12, 2010, at 1:07 PM, Thor Lancelot Simon wrote:
...
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
On Fri, Nov 12, 2010 at 06:35:32PM +, Eduardo Horvath wrote:
Take, for example, the simple act of byte swapping network data. x86 has
a bswap instruction. SPARC and PowerPC architectures have a multiplexer
on the load/store. (Don't know about MIPS, don't remember about ARM.) In
On Fri, 12 Nov 2010, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 06:35:32PM +, Eduardo Horvath wrote:
Take, for example, the simple act of byte swapping network data. x86 has
a bswap instruction. SPARC and PowerPC architectures have a multiplexer
on the load/store. (Don't
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
If you look at sys/endian.h, that is exactly the kind of abstraction the
API makes easy to use. Just provide the proper inline functions for your
platform.
No it doesen't because all those macros assume the value is being
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
If you look at sys/endian.h, that is exactly the kind of abstraction the
API makes easy to use. Just provide the proper inline functions for your
platform.
No it doesen't because all those macros assume the value is being
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
The assignment:
foo.size = htole64(size);
Cannot be replaced with:
__inline __asm(stxa %1, [%0] ASI_LITLE : foo.size : size);
Actually, it should be possible to do exactly that if you allow the
output register to be a
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
The assignment:
foo.size = htole64(size);
Cannot be replaced with:
__inline __asm(stxa %1, [%0] ASI_LITLE : foo.size : size);
Actually, it should
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
The assignment:
foo.size = htole64(size);
Cannot be replaced with:
__inline __asm(stxa %1,
On Fri, Nov 12, 2010 at 09:23:07PM +, Eduardo Horvath wrote:
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
The assignment:
foo.size =
On Fri, 12 Nov 2010, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 09:23:07PM +, Eduardo Horvath wrote:
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo
On Fri, Nov 12, 2010 at 09:29:58PM +, Eduardo Horvath wrote:
Doesn't really matter, as the compiler can reorder that and with the
right constraints, it certainly should.
So instead of a single store you force a register spill, a load, and
another store? That's even worse than 8
On Fri, Nov 12, 2010 at 03:39:07PM +0100, Joerg Sonnenberger wrote:
It is not about mainstream. Please tell me one architecture that has
been created in the last 10 years, supports at least 32bit address
space, virtual memory and doesn't support either CAS or LL/SC. I would
be very surprised
On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
this solution would break if people actually wrote code like
lock(a)
lock(b)
release(a)
release(b)
That sequence is important, lock 'a' might control the global table, and
lock 'b' a specific entry. Otherwise you have to
On Fri, Nov 12, 2010 at 01:58:59PM -0500, Paul Koning wrote:
VAX support (and for that matter, pdp11 support) is still part of gcc-current.
Yes, because a NetBSD developer brought it back to life!
--
Thor Lancelot Simont...@rek.tjls.com
We cannot
On Fri, Nov 12, 2010 at 21:29:58 +, Eduardo Horvath wrote:
On Fri, Nov 12, 2010 at 09:23:07PM +, Eduardo Horvath wrote:
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at
On Nov 12, 2010, at 4:23 PM, Eduardo Horvath wrote:
On Sat, 13 Nov 2010, Valeriy E. Ushakov wrote:
On Fri, Nov 12, 2010 at 21:59:54 +0100, Joerg Sonnenberger wrote:
On Fri, Nov 12, 2010 at 08:31:39PM +, Eduardo Horvath wrote:
The assignment:
foo.size = htole64(size);
Cannot be
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
On 2010-11-12 17:58, Mindaugas Rasiukevicius wrote:
Antti Kanteepo...@cs.hut.fi wrote:
On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote:
By reasoning that we should design for tomorrows hardware, we might as
well design explicitly for x86_64, and let all other emulate that. But
in
On 2010-11-12 18:11, Matt Thomas wrote:
I was thinking of how AVR32 implements LL/SC sematics and wondering
if I apply the same ideas to the VAX.
Basically, everytime AVR32 takes an exception it clears a flag which
was set by the load-locked instruction. Store-conditional sees the
flag was
On 2010-11-12 18:19, Antti Kantee wrote:
On Fri Nov 12 2010 at 16:58:18 +, Mindaugas Rasiukevicius wrote:
What Johnny apparently suggests is to revisit mutex(9) interface, which
is known to work very well, and optimise it for VAX. Well, I hope we
do not design MI code to be focused on VAX.
On Sat, 13 Nov 2010, Izumi Tsutsui wrote:
Wow. I guess you can add me to the list of people leaving.
There is no perfect world and we don't have enough resources.
Any help to keep support for ancient machines are appreciate, but
complaints like we should support it which prevents
On 2010-11-13 00:48, Mindaugas Rasiukevicius wrote:
Johnny Billquistb...@softjar.se wrote:
Exactly! And I would like to emphasize that this has nothing to do with
breaking of MI and MD abstraction or x86-centric view. Decision was to
provide CAS abstraction [sic!] as a primitive for MI, by
On Nov 12, 2010, at 5:32 PM, Thor Lancelot Simon wrote:
On Fri, Nov 12, 2010 at 01:58:59PM -0500, Paul Koning wrote:
VAX support (and for that matter, pdp11 support) is still part of
gcc-current.
Yes, because a NetBSD developer brought it back to life!
Ok, I get it now. Note that
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
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
On 2010-11-13 03:26, Thor Lancelot Simon wrote:
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
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
On Nov 12, 2010, at 6:49 PM, Johnny Billquist wrote:
On 2010-11-13 03:26, Thor Lancelot Simon wrote:
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
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
On 2010-11-13 04:17, Matt Thomas wrote:
On Nov 12, 2010, at 6:49 PM, Johnny Billquist wrote:
On 2010-11-13 03:26, Thor Lancelot Simon wrote:
On Sat, Nov 13, 2010 at 01:11:01AM +0100, Johnny Billquist wrote:
It's pretty clear, looking at the VAX architecture and many of the early
VAX
On Nov 12, 2010, at 7:39 PM, Johnny Billquist wrote:
Eh...?
Now I'm not following you.
Yes, if you grab a lock in some code, and then get an interrupt, and in that
interrupt routine, you try to grab the same lock, you loose.
That should be pretty obvious.
How does using CAS to implement
On 2010-11-13 04:49, Matt Thomas wrote:
On Nov 12, 2010, at 7:39 PM, Johnny Billquist wrote:
Eh...?
Now I'm not following you.
Yes, if you grab a lock in some code, and then get an interrupt, and in that
interrupt routine, you try to grab the same lock, you loose.
That should be pretty
66 matches
Mail list logo
