On Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote:
> On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
> > You can release it with either call, mutex_spin_ is just a way to avoid
> > additional atomic operations. The ususal case is adaptive mutex, but
> > stuff like the dispatch
On Wed Nov 24 2010 at 13:05:33 -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 24, 2010 at 07:56:33PM +0200, Antti Kantee wrote:
> >
> > Dunno about NetBSD specifically, but this suggests great differences:
> > http://www.netbsd.org/~ad/50/img15.html
>
> The problem is that it demonstrates that N
On Wed, Nov 24, 2010 at 07:56:33PM +0200, Antti Kantee wrote:
>
> Dunno about NetBSD specifically, but this suggests great differences:
> http://www.netbsd.org/~ad/50/img15.html
The problem is that it demonstrates that NetBSD's better *on that hardware*
than it was. There are confounding variabl
On Wed Nov 24 2010 at 12:42:44 -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 24, 2010 at 04:52:38PM +0200, Antti Kantee wrote:
> > Thanks, I'll use your list as a starting point. One question though:
> >
> > On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
> > > - build.sh on a static,
On Wed, Nov 24, 2010 at 04:52:38PM +0200, Antti Kantee wrote:
> Thanks, I'll use your list as a starting point. One question though:
>
> On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
> > - build.sh on a static, unchanging source tree.
>
> >From the SSP discussion I have a recollectio
Thanks, I'll use your list as a starting point. One question though:
On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
> - build.sh on a static, unchanging source tree.
>From the SSP discussion I have a recollection that build.sh can be
very jittery, up to the order of 1% per build. I'v
On Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote:
> On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
> > You can release it with either call, mutex_spin_ is just a way to avoid
> > additional atomic operations. The ususal case is adaptive mutex, but
> > stuff like the dispatch
On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
> You can release it with either call, mutex_spin_ is just a way to avoid
> additional atomic operations. The ususal case is adaptive mutex, but
> stuff like the dispatcher/scheduler makes use of spin mutexes exclusively
> and the fast path
> Done. Now I just need to fix hppa so that it will be happy again (as far
> as I can tell, that's the only archtecture that defines it's own mutex
> operations, apart from VAX).
i should see about re-enabling the sparc code at least for UP.
please have a look there, too...
.mrg.
Johnny Billquist wrote:
> On 2010-11-20 03:59, Simon Burge wrote:
> > Johnny Billquist wrote:
> >
> >> What I don't get is why it take so much time to even respond to
> >> pings, compared to Ultrix or VMS. What are we doing in the kernel??? As
> >> usual, I'm open to suggestions...
> >
> > Have yo
On 2010-11-20 03:59, Simon Burge wrote:
Johnny Billquist wrote:
What I don't get is why it take so much time to even respond to
pings, compared to Ultrix or VMS. What are we doing in the kernel??? As
usual, I'm open to suggestions...
Have you tried a profiling kernel? I know that can introdu
Johnny Billquist wrote:
> What I don't get is why it take so much time to even respond to
> pings, compared to Ultrix or VMS. What are we doing in the kernel??? As
> usual, I'm open to suggestions...
Have you tried a profiling kernel? I know that can introduce its own overheads,
but might poin
On 2010-11-19 13:36, Thor Lancelot Simon wrote:
On Fri, Nov 19, 2010 at 01:04:50PM +0100, Johnny Billquist wrote:
Doh! Stupid of me. I just realized how mutexes can be taken without ever
passing through mutex_enter or mutex_vector_enter, even if they are
defined. We also have mutex_tryenter, wh
On Nov,Friday 19 2010, at 1:04 PM, Johnny Billquist wrote:
> On 11/19/10 01:50, Johnny Billquist wrote:
>> mutex exit spin with unlock appears to totally have been because some
>> spin locks were managed to be taken though mutex_vector_enter, even
>> though I have a mutex_spin_enter. I have no id
On Fri, Nov 19, 2010 at 01:04:50PM +0100, Johnny Billquist wrote:
>
> Doh! Stupid of me. I just realized how mutexes can be taken without ever
> passing through mutex_enter or mutex_vector_enter, even if they are
> defined. We also have mutex_tryenter, which cannot be redefined.
So make it so
On 11/19/10 01:50, Johnny Billquist wrote:
mutex exit spin with unlock appears to totally have been because some
spin locks were managed to be taken though mutex_vector_enter, even
though I have a mutex_spin_enter. I have no idea how on earth that path
would be possible, but after changing the co
On 2010-11-19 01:16, Andrew Doran wrote:
On Wed, Nov 17, 2010 at 03:03:20PM +1100, matthew green wrote:
- hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
My recollection is that there were problems with the assembly t
On 2010-11-19 01:13, Andrew Doran wrote:
On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
On 11/17/10 11:38, Johnny Billquist wrote:
On 11/17/10 05:15, Matt Thomas wrote:
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not true
On Wed, Nov 17, 2010 at 03:03:20PM +1100, matthew green wrote:
>
> > - hppa seems to have a mutex implemented without cas. is it broken?
>
> FWIW, the sparc implementation is only broken on SMP.
My recollection is that there were problems with the assembly that we
were using, we didn't get to t
On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
> On 11/17/10 11:38, Johnny Billquist wrote:
> >On 11/17/10 05:15, Matt Thomas wrote:
> >>
> >>On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
> >>
> >>>On 2010-11-17 04:52, Matt Thomas wrote:
>
> Not true. Spinlocks mu
On Wed, Nov 17, 2010 at 07:26:04AM -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
> >
> > There are obviously a lot of calls to mutex_enter and mutex_exit with
> > spin mutexes...
>
> Indeed there are. I don't underestand what Matt said ab
On 11/17/10 05:03, matthew green wrote:
- hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
Did they use their own mutex_enter and mutex_spin_enter? If so, it might
be that the fact that mutex_vector_enter has it's own im
On 11/17/10 14:34, Andrew Doran wrote:
On Wed, Nov 17, 2010 at 07:55:13AM -0500, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
But you could perhaps argue that this is a bug in itself, and
mutex_vector_enter should not take a spin mutex on its own
On Wed, Nov 17, 2010 at 07:55:13AM -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
> >
> > But you could perhaps argue that this is a bug in itself, and
> > mutex_vector_enter should not take a spin mutex on its own when a
> > mutex_spin_ent
On 11/17/10 13:55, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
But you could perhaps argue that this is a bug in itself, and
mutex_vector_enter should not take a spin mutex on its own when a
mutex_spin_enter function exist.
I don't think that's
On Wed, Nov 17, 2010 at 01:31:51PM +0100, Johnny Billquist wrote:
>
> But you could perhaps argue that this is a bug in itself, and
> mutex_vector_enter should not take a spin mutex on its own when a
> mutex_spin_enter function exist.
I don't think that's right. I don't believe spin mutexes a
On Wednesday 17 November 2010 03:26:08 Johnny Billquist wrote:
> On 2010-11-17 04:13, YAMAMOTO Takashi wrote:
[snip]
> > - hppa seems to have a mutex implemented without cas. is it broken?
>
> I don't know, but would be very interested to hear from someone running
> -current on hppa. hppa is the
On 11/17/10 13:26, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
There are obviously a lot of calls to mutex_enter and mutex_exit with
spin mutexes...
Indeed there are. I don't underestand what Matt said about this. When
I was converting /dev/c
On Tue, Nov 16, 2010 at 07:52:13PM -0800, Matt Thomas wrote:
> Not true. Spinlocks must enter through mutex_spin_enter and adaptive mutexes
> enter through mutex_enter. The corresponding is true for exiting as well.
> The only reason mutex_vector_{enter,exit} is called to cause a panic.
No. Spin
On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
>
> There are obviously a lot of calls to mutex_enter and mutex_exit with
> spin mutexes...
Indeed there are. I don't underestand what Matt said about this. When
I was converting /dev/crypto to mutexes I am pretty sure it was ex
On Wed, Nov 17, 2010 at 11:38:54AM +0100, Johnny Billquist wrote:
> Ouch. Should I also file bugs for mutexes that are released, but
> already appear to be free?
Yes.
> Because that also happens.
LOCKDEBUG should detect this, I guess.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront t
On 11/17/10 11:38, Johnny Billquist wrote:
On 11/17/10 05:15, Matt Thomas wrote:
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not true. Spinlocks must enter through mutex_spin_enter and adaptive
mutexes
enter through mutex_enter. The correspon
On 11/17/10 05:15, Matt Thomas wrote:
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
On 2010-11-17 04:52, Matt Thomas wrote:
Not true. Spinlocks must enter through mutex_spin_enter and adaptive mutexes
enter through mutex_enter. The corresponding is true for exiting as well.
The only
On Nov 16, 2010, at 8:04 PM, Johnny Billquist wrote:
> On 2010-11-17 04:52, Matt Thomas wrote:
>>
>> Not true. Spinlocks must enter through mutex_spin_enter and adaptive mutexes
>> enter through mutex_enter. The corresponding is true for exiting as well.
>> The only reason mutex_vector_{enter,
On 2010-11-17 04:52, Matt Thomas wrote:
On Nov 16, 2010, at 7:32 PM, Johnny Billquist wrote:
On 2010-11-17 04:25, matthew green wrote:
The (my) problem is that rwlocks must use CAS as well, and I'm starting
to think that I have to use CAS for the mutex code as well, as I can't
seem to get mut
> - hppa seems to have a mutex implemented without cas. is it broken?
FWIW, the sparc implementation is only broken on SMP.
.mrg.
On Nov 16, 2010, at 7:32 PM, Johnny Billquist wrote:
> On 2010-11-17 04:25, matthew green wrote:
>>> The (my) problem is that rwlocks must use CAS as well, and I'm starting
>>> to think that I have to use CAS for the mutex code as well, as I can't
>>> seem to get mutexs work reliably without usin
On 2010-11-17 04:25, matthew green wrote:
The (my) problem is that rwlocks must use CAS as well, and I'm starting
to think that I have to use CAS for the mutex code as well, as I can't
seem to get mutexs work reliably without using the default
implementation. The mutexes are used and abused in wa
On 2010-11-17 04:13, YAMAMOTO Takashi wrote:
hi,
On 2010-11-16 19:32, Eric Haszlakiewicz wrote:
On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the "eat your CAS whether you like it or not"
side of the fen
> The (my) problem is that rwlocks must use CAS as well, and I'm starting
> to think that I have to use CAS for the mutex code as well, as I can't
> seem to get mutexs work reliably without using the default
> implementation. The mutexes are used and abused in ways that seems to
> make a lot o
FWIW, there *are* sparc implementations of the mutex vector
functions, but we had to disable them because of lossage we
we not able to (yet) track down. they mostly work, so may
be useful for at least reading.
.mrg.
hi,
> On 2010-11-16 19:32, Eric Haszlakiewicz wrote:
>> On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
>>> On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the "eat your CAS whether you like it or not"
side of the fence explain why the following ide
On 2010-11-16 19:32, Eric Haszlakiewicz wrote:
On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the "eat your CAS whether you like it or not"
side of the fence explain why the following idea would not work:
O
On 2010-11-16 18:44, Matt Thomas wrote:
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
Please could somebody on the "eat your CAS whether you like it or not"
side of the fence explain why the following idea would not work:
On Sat, 13 Nov 2010, der Mouse wrote:
Consider this hypothetical:
On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
> On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
> > Please could somebody on the "eat your CAS whether you like it or not"
> > side of the fence explain why the following idea would not work:
> >
> > On Sat, 13 Nov 2010, der Mouse wro
On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
> Please could somebody on the "eat your CAS whether you like it or not"
> side of the fence explain why the following idea would not work:
>
> On Sat, 13 Nov 2010, der Mouse wrote:
>> Consider this hypothetical:
>>
>> x86 does #define ATOMIC_OPS
Please could somebody on the "eat your CAS whether you like it or not"
side of the fence explain why the following idea would not work:
On Sat, 13 Nov 2010, der Mouse wrote:
> Consider this hypothetical:
>
> x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code
> notices this and defin
On 11/15/10 14:55, Johnny Billquist wrote:
On 11/14/10 20:16, David Holland wrote:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, 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
On 11/14/10 20:16, David Holland wrote:
On Sat, Nov 13, 2010 at 01:45:40AM +0900, 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 a
On Sat, Nov 13, 2010 at 01:45:40AM +0900, 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
Just a note to avoid having incorrect information in the archives
without a correction. I wrote:
> [%] It occurs to me, the VAX's BBSSI and BBCCI _are_ CAS, just
> restricted to a one-bit-wide operand (and with the data-to-swap-in
> specified by choice of instruction rather than an operand).
Thi
On Fri, Nov 12, 2010 at 02:21:34PM +0100, Johnny Billquist wrote:
> > > then I realized that this solution would break if people actually
> > > wrote code like
> > > lock(a)
> > > lock(b)
> > > release(a)
> > > release(b)
> >
> >...which is very common.
>
> It is? I would hav
> Already wrote about reasoning in other reply to mouse (keywords: no
> code duplication, better design), so wont repeat myself.
Except you appear to think that the only options are the current state
and each arch totally doing its own thing.
There are places other than those two to draw the divi
> Hadn't it been much nicer of we just had the mutex and lock
> abstraction, and left the whole implementation to each MD part?
Exactly. Consider this hypothetical:
x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code
notices this and defines all the higher-level primitives (if that'
On Nov,Friday 12 2010, at 5:32 PM, Mindaugas Rasiukevicius wrote:
> Andrew Doran 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..
That would make everyone happy.
Regards
On 2010-11-13 00:48, Mindaugas Rasiukevicius wrote:
Johnny Billquist 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 the MD land -
in
> 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 improvements
of mainstream will just make NetBSD rotte
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 improvemen
On 2010-11-12 23:37, David Laight wrote:
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 spec
Johnny Billquist 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 the MD land -
> > in a same way, like we have copy(9), fetch
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 2010-11-12 17:58, Mindaugas Rasiukevicius wrote:
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 bel
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 m
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 e
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 surpr
der Mouse 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 break-through for better
> 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 Open
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 s
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 it, so I'm
> working on getting away from this. (
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
> 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 ha
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.
> >
> >
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 above su
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
* 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
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.
It'
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 aw
Andrew Doran 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 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 to
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.
It'
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.
> >> 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 co
> 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 MI AP
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 t
> > 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.
> Compilers that page themselves to death unless given over twice the RAM
> a uV2 maxes out at. D
On 11/12/10 15:56, der Mouse 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.
What's that got to do with it?
NetBSD used to be about pro
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 o
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
> > con
> 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
On Fri, Nov 12, 2010 at 02:35:59PM +0100, Johnny Billquist wrote:
> What I am observing is how slow NetBSD have become, which is very
> obvious on a platform like the VAX. Running something like Ultrix
> runs circles around NetBSD nowadays.
That's to be expected. Ultrix is a far less capable sys
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 inherent
>> 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 lucky accident than a desired goal?
Looks to me like prett
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 m
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 abo
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 implem
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
dif
On 11/12/10 15:05, Martin Husemann wrote:
On Fri, Nov 12, 2010 at 02:35:59PM +0100, Johnny Billquist wrote:
What I am observing is how slow NetBSD have become, which is very
obvious on a platform like the VAX. Running something like Ultrix
runs circles around NetBSD nowadays. And I'm trying to f
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'
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 cheap
On Fri, Nov 12, 2010 at 02:35:59PM +0100, Johnny Billquist wrote:
> What I am observing is how slow NetBSD have become, which is very
> obvious on a platform like the VAX. Running something like Ultrix
> runs circles around NetBSD nowadays. And I'm trying to find where
> all the CPU cycles are goin
1 - 100 of 116 matches
Mail list logo
