Re: atf for atomic_ops(3)
On Sun, Feb 17, 2019 at 04:43:52PM +0900, Tetsuya Isaki wrote: > I wrote atf tests for atomic_ops(3). > These does not test the atomicity but can find a easy bug. > Is this ok to commit? > (I know there is a similar path tests/lib/libc/sync but > I think it's better to not merge) Why not? Or we could remove all ops from tests/lib/libc/sync that are covered in this tests, and if that test covers all, remove tests/lib/libc/sync completly. The rationaly for tests/lib/libc/sync was just to spot missing symbols, if we even test the function, that is obviously better. Martin
atf for atomic_ops(3)
I wrote atf tests for atomic_ops(3).
These does not test the atomicity but can find a easy bug.
Is this ok to commit?
(I know there is a similar path tests/lib/libc/sync but
I think it's better to not merge)
Thanks,
---
Tetsuya Isaki
Index: distrib/sets/lists/tests/mi
===
RCS file: /cvsroot/src/distrib/sets/lists/tests/mi,v
retrieving revision 1.806
diff -u -r1.806 mi
--- distrib/sets/lists/tests/mi 9 Feb 2019 00:14:43 - 1.806
+++ distrib/sets/lists/tests/mi 17 Feb 2019 07:10:08 -
@@ -2442,6 +2442,15 @@
./usr/tests/lib/libc tests-lib-tests
compattestfile,atf
./usr/tests/lib/libc/Atffile tests-lib-tests
compattestfile,atf
./usr/tests/lib/libc/Kyuafile tests-lib-tests
compattestfile,atf,kyua
+./usr/tests/lib/libc/atomictests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/Atffiletests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_add tests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_and tests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_cas tests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_dec tests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_inc tests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_ortests-lib-tests
compattestfile,atf
+./usr/tests/lib/libc/atomic/t_atomic_swap tests-lib-tests
compattestfile,atf
./usr/tests/lib/libc/c063 tests-lib-tests
compattestfile,atf
./usr/tests/lib/libc/c063/Atffile tests-lib-tests
compattestfile,atf
./usr/tests/lib/libc/c063/Kyuafile tests-lib-tests
compattestfile,atf,kyua
Index: tests/lib/libc/Makefile
===
RCS file: /cvsroot/src/tests/lib/libc/Makefile,v
retrieving revision 1.48
diff -u -r1.48 Makefile
--- tests/lib/libc/Makefile 3 Aug 2018 04:24:41 - 1.48
+++ tests/lib/libc/Makefile 17 Feb 2019 07:10:55 -
@@ -5,6 +5,7 @@
SUBDIR+= tls_dso .WAIT sync
+TESTS_SUBDIRS+=atomic
TESTS_SUBDIRS+=c063 db gen hash inet locale misc net regex rpc setjmp
stdlib
TESTS_SUBDIRS+=stdio string sys termios time tls ttyio
--- /dev/null 2019-02-17 16:04:39.0 +0900
+++ tests/lib/libc/atomic/Makefile 2019-02-16 13:02:37.0 +0900
@@ -0,0 +1,19 @@
+# $NetBSD$
+
+.include
+
+TESTSDIR= ${TESTSBASE}/lib/libc/atomic
+
+TESTS_C+= t_atomic_add
+TESTS_C+= t_atomic_and
+TESTS_C+= t_atomic_cas
+TESTS_C+= t_atomic_dec
+TESTS_C+= t_atomic_inc
+TESTS_C+= t_atomic_or
+TESTS_C+= t_atomic_swap
+
+MKMAN=no
+
+BINDIR=${TESTSDIR}
+
+.include
--- /dev/null 2019-02-17 16:04:39.0 +0900
+++ tests/lib/libc/atomic/t_atomic_add.c2019-02-16 19:25:48.0
+0900
@@ -0,0 +1,102 @@
+/* $NetBSD$*/
+
+/* XXX License */
+
+#include
+__RCSID("$NetBSD$");
+
+#include
+#include
+#include
+
+/*
+ * These tests don't examine the atomicity.
+ */
+
+#define DST(0x1122334455667788UL)
+#define SRC(0xf0e0d0c0b0a09081UL)
+#define EXPECT (0x0203040506070809UL)
+
+/*
+ * atomic_add_*()
+ */
+#define atf_add(NAME, DTYPE, STYPE, FMT) \
+ATF_TC(NAME); \
+ATF_TC_HEAD(NAME, tc) \
+{ \
+ atf_tc_set_md_var(tc, "descr", #NAME); \
+} \
+ATF_TC_BODY(NAME, tc) \
+{ \
+ volatile DTYPE val; \
+ STYPE src; \
+ DTYPE exp; \
+ val = (DTYPE)DST; \
+ src = (STYPE)SRC; \
+ exp = (DTYPE)EXPECT; \
+ NAME(&val, src); \
+ ATF_REQUIRE_MSG(val == exp, \
+ "val expects " FMT " but " FMT, exp, val); \
+}
+
+atf_add(atomic_add_32, uint32_t, int32_t, "0x%" PRIx32);
+atf_add(atomic_add_int, unsigned int, int, "0x%x");
+atf_add(atomic_add_long, unsigned long, long,"0x%lx");
+atf_add(atomic_add_ptr, void *,ssize_t, "%p");
+#if defined(__HAVE_ATOMIC64_OPS)
+atf_add(atomic_add_64, uint64_t, int64_t, "0x%" PRIx64);
+#endif
+
+/*
+ * atomic_add_*_nv()
+ */
+#define atf_add_nv(NAME, DTYPE, STYPE, FMT) \
+ATF_TC(NAME); \
+ATF_TC_HEAD(NAME, tc) \
+{ \
+ atf_tc_set_md_var(tc, "descr", #NAME); \
+} \
+ATF_TC_BODY(NAME, tc) \
+{ \
+ volatile DTYPE val; \
+ STYPE src; \
+ DTYPE res; \
+ DTYPE exp; \
+ val = (DTYPE)DST; \
+ src = (STYPE)SRC; \
+ exp = (DTYPE)EXPECT; \
+ res = NAME(&val, src); \
+ ATF_REQUIRE_MSG(val == exp, \
+ "val expects " FMT " but " FMT, exp, val); \
+ ATF_REQUIRE_MSG(res == exp, \
+ "res expects " FMT " but " FMT, exp, res); \
+}
+
+atf_add_nv(atomic_add_32_nv, uint32_t, int32_t, "0x%" PRIx32);
+atf_add_
Re: Reserve device major numbers for pkgsrc
On Feb 16, 11:25pm, Kamil Rytarowski wrote: } } We started to build and ship kernel modules through pkgsrc. This is a really good thing and is part of the reason why modules exist. } I would like to reserve 3 major numbers for the HAXM case from the base } pool of devices and prevent potential future conflicts and compatibility } breakage due to picking up another major number in a 3rd party software. } } Where and how to reserve these major numbers? The ideal thing is to not reserve numbers at all and have them allocated dynamically. This requires the module reporting the number that was allocated to userland somehow. However, the only thing that is coming to mind off the top of my head is printf(9) which would normally land in /var/log/messages. This is obviously not very convenient. Does anybody else have thoughts on this? Maybe we need to extend modctl(MODCTL_LOAD, ...) to be able to return information from the loaded module? Of course, the real ideal thing would be to get a devfs and get rid of the concept of major numbers. Here I go again, starting contriversies. :-> }-- End of excerpt from Kamil Rytarowski
Re: fork-the-syscall return semantics
On Sat, Feb 16, 2019 at 20:14:35 -0500, Mouse wrote:
> In fork1(), in kern/kern_fork.c, there is code
>
> /*
> * Return child pid to parent process,
> * marking us as parent via retval[1].
> */
> if (retval != NULL) {
> retval[0] = p2->p_pid;
> retval[1] = 0;
> }
>
> This is very old code; identical code appears as far back as 1.4T,
> quite likely even farther back. It appears the return semantics of
> fork-the-syscall-trap (and related calls, like __vfork14) are a bit
> odd: the parent returns and the child returns (or
> at least so a comment in the SPARC libc wrapper claims; I haven't dug
> enough to find the kernel code where the child's return values are set
> up). But I see no reason for this, as the libc wrapper immediately
> destroys the first return value in the child.
>
> Does anyone happen to know why this was done? So far I haven't found
> any reason to not simply return the abstract return value in retval[0]
> like most other syscalls that return a simple integer value, but for a
> special case like this to have survived this long, I can't help feeling
> there must be _something_ behind it.
I would look at
http://mail-index.netbsd.org/source-changes/1995/12/10/msg012114.html
Modified Files:
init_main.c
Log Message:
Change the way we test whether or not we're in the child process.
except there seems to be no such commit actually recorded in
init_main.c log :) Was reverted in the repo, I guess.
The code before that change looks like:
#ifdef cpu_set_init_frame /* XXX should go away */
if (rval[1]) {
/*
* Now in process 2.
*/
start_pagedaemon(curproc);
}
#else
Its counterpart is
http://mail-index.netbsd.org/source-changes/1995/12/10/msg012115.html
Modified Files:
kern_fork.c
Log Message:
If __FORK_BRAINDAMAGE, continue stuffing retval[1] for the benefit of main().
Other relevant commits are probably:
http://mail-index.netbsd.org/source-changes/1995/12/09/.html
http://mail-index.netbsd.org/source-changes/1995/12/09/msg012096.html
http://mail-index.netbsd.org/source-changes/1995/12/09/msg012098.html
-uwe
fork-the-syscall return semantics
In fork1(), in kern/kern_fork.c, there is code
/*
* Return child pid to parent process,
* marking us as parent via retval[1].
*/
if (retval != NULL) {
retval[0] = p2->p_pid;
retval[1] = 0;
}
This is very old code; identical code appears as far back as 1.4T,
quite likely even farther back. It appears the return semantics of
fork-the-syscall-trap (and related calls, like __vfork14) are a bit
odd: the parent returns and the child returns (or
at least so a comment in the SPARC libc wrapper claims; I haven't dug
enough to find the kernel code where the child's return values are set
up). But I see no reason for this, as the libc wrapper immediately
destroys the first return value in the child.
Does anyone happen to know why this was done? So far I haven't found
any reason to not simply return the abstract return value in retval[0]
like most other syscalls that return a simple integer value, but for a
special case like this to have survived this long, I can't help feeling
there must be _something_ behind it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Reserve device major numbers for pkgsrc
On Sat, Feb 16, 2019 at 11:25:36PM +0100, Kamil Rytarowski wrote: > We started to build and ship kernel modules through pkgsrc. We did a long time ago, sort of... > I would like to reserve 3 major numbers for the HAXM case from the base > pool of devices and prevent potential future conflicts and compatibility > breakage due to picking up another major number in a 3rd party software. > > Where and how to reserve these major numbers? > > I expect that we will start growing software that uses our kernel module > framework. (I have got few candidates to get ported in future) > Some history from AFS/OpenAFS/Arla: Our base system reserves a syscall number (210) for the AFS syscall, which is used either by the OpenAFS kernel module, or the Arla nnpfs kernel module. (Neither of these modules are currently functional with modern NetBSD.) Arla nnpfs additionally used a character device major, which it IIRC allocated dynamically at module load time, which was then somehow conveyed to userland to mknod the necessary device special before starting arlad. I'd suggest similar for this: allocate a MI range of character and block majors for quasi-external use, and then make registrations for your needs. Jonathan Kollasch P.S. Maybe reserve the first character major in the block for nnpfs as a sort of monument to Arla (which is pretty much abandoned these days).
Re: Reserve device major numbers for pkgsrc
New version. http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.2.txt I have no preference on preallocation and selection of numbers. On 17.02.2019 00:12, Jaromír Doleček wrote: > Perhaps do not pre-reserve anything and simply reserve consecutive > numbers as the need arises? > > Le sam. 16 févr. 2019 à 23:55, Kamil Rytarowski a écrit : >> >> On 16.02.2019 23:40, Jaromír Doleček wrote: >>> Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : We started to build and ship kernel modules through pkgsrc. I would like to reserve 3 major numbers for the HAXM case from the base pool of devices and prevent potential future conflicts and compatibility breakage due to picking up another major number in a 3rd party software. Where and how to reserve these major numbers? I expect that we will start growing software that uses our kernel module framework. (I have got few candidates to get ported in future) >>> >>> See sys/conf/majors >>> >>> Jaromir >>> >> >> Proposed patch: >> >> http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.txt >> >> I have no opinion on numbers to pick, please suggest the right ranges >> and I will follow it. >> signature.asc Description: OpenPGP digital signature
Re: Reserve device major numbers for pkgsrc
Perhaps do not pre-reserve anything and simply reserve consecutive numbers as the need arises? Le sam. 16 févr. 2019 à 23:55, Kamil Rytarowski a écrit : > > On 16.02.2019 23:40, Jaromír Doleček wrote: > > Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : > >> > >> We started to build and ship kernel modules through pkgsrc. > >> > >> I would like to reserve 3 major numbers for the HAXM case from the base > >> pool of devices and prevent potential future conflicts and compatibility > >> breakage due to picking up another major number in a 3rd party software. > >> > >> Where and how to reserve these major numbers? > >> > >> I expect that we will start growing software that uses our kernel module > >> framework. (I have got few candidates to get ported in future) > > > > See sys/conf/majors > > > > Jaromir > > > > Proposed patch: > > http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.txt > > I have no opinion on numbers to pick, please suggest the right ranges > and I will follow it. >
Re: Reserve device major numbers for pkgsrc
On 16.02.2019 23:40, Jaromír Doleček wrote: > Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : >> >> We started to build and ship kernel modules through pkgsrc. >> >> I would like to reserve 3 major numbers for the HAXM case from the base >> pool of devices and prevent potential future conflicts and compatibility >> breakage due to picking up another major number in a 3rd party software. >> >> Where and how to reserve these major numbers? >> >> I expect that we will start growing software that uses our kernel module >> framework. (I have got few candidates to get ported in future) > > See sys/conf/majors > > Jaromir > Proposed patch: http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.txt I have no opinion on numbers to pick, please suggest the right ranges and I will follow it. signature.asc Description: OpenPGP digital signature
Re: Reserve device major numbers for pkgsrc
Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : > > We started to build and ship kernel modules through pkgsrc. > > I would like to reserve 3 major numbers for the HAXM case from the base > pool of devices and prevent potential future conflicts and compatibility > breakage due to picking up another major number in a 3rd party software. > > Where and how to reserve these major numbers? > > I expect that we will start growing software that uses our kernel module > framework. (I have got few candidates to get ported in future) See sys/conf/majors Jaromir
Reserve device major numbers for pkgsrc
We started to build and ship kernel modules through pkgsrc. I would like to reserve 3 major numbers for the HAXM case from the base pool of devices and prevent potential future conflicts and compatibility breakage due to picking up another major number in a 3rd party software. Where and how to reserve these major numbers? I expect that we will start growing software that uses our kernel module framework. (I have got few candidates to get ported in future) signature.asc Description: OpenPGP digital signature
