Re: CVS commit: src/sys/rump/librump/rumpkern
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 commit: cvs rdiff -u -r1.169 -r1.170 src/sys/rump/librump/rumpkern/Makefile.rumpkern Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5976d0ab241195299513085! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/rump/librump/rumpkern
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: Add a lockless uniprocessor version of atomic_cas_generic.c, which is currently used by all the archs that previously used cas_generic. This break arm platform builds. /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/libc/arch/arm/atomic/atomic_cas_up.S: Assembler messages: /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/libc/arch/arm/atomic/atomic_cas_up.S:38: Error: bad instruction `ras_start_asm_hidden(_atomic_cas)' /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/libc/arch/arm/atomic/atomic_cas_up.S:42: Error: bad instruction `ras_end_asm_hidden(_atomic_cas)' *** [atomic_cas_up.pico] Error code 1 Nick
Re: CVS commit: src/sys/rump/librump/rumpkern
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: src/sys/rump/librump/rumpkern: Makefile.rumpkern Added Files: src/sys/rump/librump/rumpkern: atomic_cas_up.c Log Message: Add a lockless uniprocessor version of atomic_cas_generic.c, which is currently used by all the archs that previously used cas_generic. This break arm platform builds. /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/li bc/arch/arm/atomic/atomic_cas_up.S: Assembler messages: /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/li bc/arch/arm/atomic/atomic_cas_up.S:38: Error: bad instruction `ras_start_asm_hidden(_atomic_cas)' /usr/src/lib/librump/../../sys/rump/../lib/libkern/../../../common/lib/li bc/arch/arm/atomic/atomic_cas_up.S:42: Error: bad instruction `ras_end_asm_hidden(_atomic_cas)' *** [atomic_cas_up.pico] Error code 1 Fixed. I'll run a build just to make sure. Thanks for the quick response. Nick
Re: CVS commit: src/sys/rump/librump/rumpkern
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: --- dependall-dev --- WARNING: pseudo-root is an experimental feature /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:8: audiobus*: unknown device `audiobus' /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:10: `audio* at audiobus?' is orphaned (nothing matching `audiobus?' found) *** Stop. *** [ioconf.c] Error code 1 1 error nbmake: stopped in /home/netbsd/src/sys/rump/dev/lib/libaudio *** [dependall-libaudio] Error code 2 1 error Can you elaborate why, and how to get it working? Other than rump, it was tested. -- Mindaugas
Re: CVS commit: src/sys/rump/librump/rumpkern
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 `audiobus' /home/netbsd/src/sys/rump/dev/lib/libaudio/AUDIO.ioconf:10: `audio* at audiobus?' is orphaned (nothing matching `audiobus?' found) *** Stop. *** [ioconf.c] Error code 1 1 error nbmake: stopped in /home/netbsd/src/sys/rump/dev/lib/libaudio *** [dependall-libaudio] Error code 2 1 error Can you elaborate why, and how to get it working? I suspect your config(1) is too old and config should whine about it. At least my nb5 config displays the appropriate error for -current sources: WARNING: ioconf is an experimental feature /sys/conf/files:4: your sources require a newer version of config(1) -- please rebuild it. /sys/conf/majors:12: syntax error /sys/conf/majors:13: syntax error /sys/conf/majors:15: syntax error /sys/conf/majors:18: syntax error /sys/conf/majors:19: syntax error /sys/conf/majors:21: syntax error /sys/conf/majors:25: syntax error /sys/conf/majors:26: syntax error /sys/conf/majors:27: syntax error /sys/conf/majors:28: syntax error /sys/conf/majors:29: syntax error /sys/conf/majors:30: syntax error /sys/conf/majors:33: syntax error /sys/conf/majors:37: syntax error /sys/conf/majors:41: syntax error /sys/conf/majors:43: syntax error WARNING: pseudo-root is an experimental feature AUDIO.ioconf:8: audiobus*: unknown device `audiobus' AUDIO.ioconf:10: `audio* at audiobus?' is orphaned (nothing matching `audiobus?' found) *** Stop. Guessing from the log you pasted and that the bottom matches my too-old config's error reportable, you were bit by -j output and did not see the real error message. Try upgrading your tools and if the problem persists, let me know. Other than rump, it was tested. The point was more that you did not make an effort to run the regression test suite. (anyway, it's done now, and the commits come out clean. thanks for the features)
Re: CVS commit: src/sys/rump/librump/rumpkern
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 false. Arguably we shouhld fix our gcc to only define __i386__, not i386, which conflicts with the user namespace... i agree. i was going to reply to an earlier message on this that it was the kernel Makefile's that define $MACHINE, but upon looking at them i noticed that only a few do, and that i486--netbsdelf-gcc defines i386 all the time so i didn't send any email. we should audit all of our gcc configs and kernel configs to deal. Yes, I agree, too. Quite some time ago, we stopped defining unix, which mainly caused issues in pkgsrc and not in src, but nothing we couldn't overcome given time and bulk builds. Now's not the time, though, please leave it 2 weeks :-) Best, Alistair
re: CVS commit: src/sys/rump/librump/rumpkern
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 i386, which conflicts with the user namespace... i agree. i was going to reply to an earlier message on this that it was the kernel Makefile's that define $MACHINE, but upon looking at them i noticed that only a few do, and that i486--netbsdelf-gcc defines i386 all the time so i didn't send any email. we should audit all of our gcc configs and kernel configs to deal. .mrg.
Re: CVS commit: src/sys/rump/librump/rumpkern
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 defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. [...] -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
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 #4: [...] After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. [...] 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).
Re: CVS commit: src/sys/rump/librump/rumpkern
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 ;-) Martin
Re: CVS commit: src/sys/rump/librump/rumpkern
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 should or not, our i386 gcc predefines i386, so you probably got 0 == 0 and 1 == 0 respectively. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
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, the latter didn't). For me both end up as 0==0 and return true ;-) 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).
Re: CVS commit: src/sys/rump/librump/rumpkern
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 true, the latter didn't). What were you compiling on? Whether it should or not, our i386 gcc predefines i386, so you probably got 0 == 0 and 1 == 0 respectively. Ah, ok, now I see what happened. thanks
Re: CVS commit: src/sys/rump/librump/rumpkern
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 - /dev/null what is defined on your arch you can make an educated guess. But sure, you can't realy tell whether someone did a #define sun3 1 somewhere in the code. Martin
Re: CVS commit: src/sys/rump/librump/rumpkern
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. :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 defined :unary operator have been performed, all remaining identifiers :(including those lexically identical to keywords) are replaced with :the pp-number 0, and then each preprocessing token is converted into :a token. The resulting tokens compose the controlling constant :expression which is evaluated according to the rules of 6.6. [...] : : 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). 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. Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
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 i386, which conflicts with the user namespace... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
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, i386 expands to '1', so the : second one would be false. : : Arguably we shouhld fix our gcc to only define __i386__, not i386, : which conflicts with the user namespace... True, but doing so would likely break applications that have depended on this define. Which is worse? Warner
Re: CVS commit: src/sys/rump/librump/rumpkern
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 other breaking news, the sky is blue. :-p :-) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/sys/rump/librump/rumpkern
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 locklessing algorithms which depend on
globally atomic state.
...in other breaking news, the sky is blue.
Yet it is not possible everywhere to observe the sky being blue due to
various layers of unnecessary crap.
:-p :-)
?:-% ('\/)
Re: CVS commit: src/sys/rump/librump/rumpkern
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 fixing. Christoph
re: CVS commit: src/sys/rump/librump/rumpkern
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 fixing. when you make a big change like your pmap change you should *ALWAYS* full release before checking in. just one platform would be sufficient. .mrg.
