pullup to 8.0?
On Tue, 25 Jul 2017, Ryota Ozaki wrote:
Module Name:src
Committed By: ozaki-r
Date: Tue Jul 25 05:01:25 UTC 2017
Modified Files:
src/sys/rump/librump/rumpkern: Makefile.rumpkern
Log Message:
Add localcount to rump kernels
To generate a diff of this
On Sunday 21 November 2010 21:46:43 Antti Kantee wrote:
Module Name: src
Committed By: pooka
Date: Sun Nov 21 21:46:43 UTC 2010
Modified Files:
src/sys/rump/librump/rumpkern: Makefile.rumpkern
Added Files:
src/sys/rump/librump/rumpkern: atomic_cas_up.c
Log Message:
On Monday 22 November 2010 10:51:03 Antti Kantee wrote:
On Mon Nov 22 2010 at 10:35:00 +, Nick Hudson wrote:
On Sunday 21 November 2010 21:46:43 Antti Kantee wrote:
Module Name: src
Committed By: pooka
Date: Sun Nov 21 21:46:43 UTC 2010
Modified Files:
Module Name:src
Committed By: pooka
Date: Wed Jun 23 08:36:03 UTC 2010
Modified Files:
src/sys/rump/librump/rumpkern: emul.c
Log Message:
As normal, fix breakage from untested commits by rmind.
Well, when I tried ./build.sh rumptest, it gave me this:
---
On Wed Jun 23 2010 at 12:39:17 +0100, Mindaugas Rasiukevicius wrote:
Well, when I tried ./build.sh rumptest, it gave me this:
--- dependall-dev ---
WARNING: pseudo-root is an experimental feature
/home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:8: audiobus*: unknown
device
On Tue, Jun 15, 2010 at 04:40:24PM +1000, matthew green wrote:
On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote:
On i386, that's true. amd64 expands to '0', as does sun3. This makes
the first one true. The second one, i386 expands to '1', so the
second one would be
On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote:
On i386, that's true. amd64 expands to '0', as does sun3. This makes
the first one true. The second one, i386 expands to '1', so the
second one would be false.
Arguably we shouhld fix our gcc to only define __i386__,
On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote:
Fix previous in emul.c -- only numbers are operands for cpp comparisons.
Apparently non-numbers logically produce arch-dependent behaviour.
Not at all.
C99 6.10.1 #4:
[...] After all replacements due to macro expansion and the
On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote:
On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote:
Fix previous in emul.c -- only numbers are operands for cpp comparisons.
Apparently non-numbers logically produce arch-dependent behaviour.
Not at all.
C99 6.10.1
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote:
So, you being the person who attempted to write cpp with sed, what
comparison does amd64 == sun3 actually result in? What about
i386 == sun3 (the former returned true, the latter didn't).
For me both end up as 0==0 and return true
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote:
So, you being the person who attempted to write cpp with sed, what
comparison does amd64 == sun3 actually result in? What about
i386 == sun3 (the former returned true, the latter didn't).
What were you compiling on? Whether it
On Mon Jun 14 2010 at 11:13:23 +0200, Martin Husemann wrote:
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote:
So, you being the person who attempted to write cpp with sed, what
comparison does amd64 == sun3 actually result in? What about
i386 == sun3 (the former returned true,
On Mon Jun 14 2010 at 09:17:43 +, David Holland wrote:
On Mon, Jun 14, 2010 at 11:34:24AM +0300, Antti Kantee wrote:
So, you being the person who attempted to write cpp with sed, what
comparison does amd64 == sun3 actually result in? What about
i386 == sun3 (the former returned
On Mon, Jun 14, 2010 at 12:27:43PM +0300, Antti Kantee wrote:
How can you tell what they end up as? I can only see that the line
wrapped in the #if is missing from output of cc -E (still on/targetting
i386).
Well, knowing the standard (as David cited) and checking with
cc -dM -E -
In message: 20100614083424.gc16...@cs.hut.fi
Antti Kantee po...@cs.hut.fi writes:
: On Mon Jun 14 2010 at 07:00:05 +, David Holland wrote:
: On Sun, Jun 13, 2010 at 03:17:02PM +, Antti Kantee wrote:
:Fix previous in emul.c -- only numbers are operands for cpp comparisons.
On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote:
On i386, that's true. amd64 expands to '0', as does sun3. This makes
the first one true. The second one, i386 expands to '1', so the
second one would be false.
Arguably we shouhld fix our gcc to only define __i386__, not
In message: 20100615052154.gb16...@netbsd.org
David Holland dholland-sourcechan...@netbsd.org writes:
: On Mon, Jun 14, 2010 at 09:40:37AM -0600, M. Warner Losh wrote:
: On i386, that's true. amd64 expands to '0', as does sun3. This makes
: the first one true. The second one,
On Tue, May 18, 2010 at 04:29:36PM +, Antti Kantee wrote:
It's pretty obvious that in terms of scalability simple workload
partitioning and replication into multiple kernels wins hands down
over complicated locking or locklessing algorithms which depend on
globally atomic state.
...in
On Thu May 20 2010 at 02:47:16 +, David Holland wrote:
On Tue, May 18, 2010 at 04:29:36PM +, Antti Kantee wrote:
It's pretty obvious that in terms of scalability simple workload
partitioning and replication into multiple kernels wins hands down
over complicated locking or
David Laight wrote:
Module Name: src
Committed By: dsl
Date: Sat Nov 7 12:08:35 UTC 2009
Modified Files:
src/sys/rump/librump/rumpkern: pmap_stub.c
Log Message:
Fix stub prototype
Doh! rump is not build as part of any kernel.
Hence gcc didn't catch it.
Thanks for
David Laight wrote:
Module Name: src
Committed By: dsl
Date: Sat Nov 7 12:08:35 UTC 2009
Modified Files:
src/sys/rump/librump/rumpkern: pmap_stub.c
Log Message:
Fix stub prototype
Doh! rump is not build as part of
21 matches
Mail list logo
