Helper programs are programs, not tests, so build them appropriately.

Thie removes the need for custom Atffiles whose only purpose was to exclude
the helpers that had been built as tests.

branches: 1.1.2; 1.1.6; 1.1.12;
add some exec() tests

Get rid of all the -lrumpdev and -lrumpvfs that are no longer needed
after moving rump's mainbus from rumpdev to rumpkern.

Produces the same atf-run results as before.

branches: 1.9.14;
revert, fixing the real cause.

Add more indirect library dependencies

Extra libs for rump.

branches: 1.6.2;
Define _KERNTYPES for things that need it.

Helper programs are programs, not tests, so build them appropriately.

Thie removes the need for custom Atffiles whose only purpose was to exclude
the helpers that had been built as tests.

branches: 1.4.4; 1.4.10;
add test case for multithreaded client calling exec

branches: 1.3.2;
no need to create a hardlinked name for the helper, just fake argv[]

add some exec() tests

Add test which checks rumpclient does not use fds 0-2 for its
internal purposes.

fix typos in comments and one definition, mainly s/sucket/socket/.

branches: 1.6.2;
test rumpclient_vfork()

no need to create a hardlinked name for the helper, just fake argv[]

Don't use hijack here since exec is now easy in pure rump clients.

remove unnecessary debug printf

test FD_CLOEXEC

add some exec() tests

Turn off the PR 49140 logging, because it itself makes the test fail.

As usual, ATF is actively interfering with test debugging. Almost all
runs in the past few days have failed this test with "stdout not
empty". In one run it timed out:
http://releng.netbsd.org/b5reports/i386/build/2016.11.22.06.51.14/test.html
but in this case ATF helpfully suppressed the log data.

Maybe if someone can figure out how to make the test hang reliably
then they can turn the logging on again and run it outside of ATF to
see what's happening.

In the meantime this problem is not likely to get fixed until we have
a less obstructive testing framework.

As a debugging measure for PR 49141, log what this is doing as it runs
to stdout. Hopefully this will get reported when the test fails in the
testbed rather than just causing ATF to report that it printed
unexpected output.

More of previous.

If pthread_create fails, report the error instead of discarding it.

branches: 1.3.2;
Update hardcoded fd expectations now that rump kernels open 0/1/2.
(since we exec, it's convenient to just assume the values of first 4 fds)

branches: 1.2.22;
Enable the "send a lot of syscall requests before exec" code, since
it works now. (or at least works in my tests)

add test case for multithreaded client calling exec

librumpclient/t_exec: Sprinkle more diagnostic information.

Let's see exactly what rump.sockstat printed since these tests have
been intermittently failing for a while:

https://releng.netbsd.org/b5reports/i386/2025/2025.03.02.08.14.26/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.02.14.13.22/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.04.00.41.00/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.04.16.40.46/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.08.19.09.46/test.html#lib_librumpclient_t_exec_threxec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.09.18.50.20/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.09.18.58.18/test.html#lib_librumpclient_t_exec_cloexec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.09.22.06.28/test.html#lib_librumpclient_t_exec_cloexec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.10.05.06.02/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.11.05.48.26/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.11.14.13.45/test.html#lib_librumpclient_t_exec_cloexec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.12.07.57.05/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.14.06.40.51/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.14.18.50.03/test.html#lib_librumpclient_t_exec_threxec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.18.07.58.09/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.19.18.15.27/test.html#lib_librumpclient_t_exec_cloexec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.21.07.09.58/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.24.00.13.58/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.26.00.05.56/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.29.11.51.54/test.html#lib_librumpclient_t_exec_threxec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.29.17.29.20/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.29.21.45.08/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.30.14.13.59/test.html#lib_librumpclient_t_exec_threxec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.30.16.23.13/test.html#lib_librumpclient_t_exec_threxec
https://releng.netbsd.org/b5reports/i386/2025/2025.03.31.13.03.23/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.03.31.14.46.42/test.html#lib_librumpclient_t_exec_threxec
https://releng.netbsd.org/b5reports/i386/2025/2025.04.01.23.02.29/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.04.02.17.44.07/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.04.03.14.51.37/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.04.03.17.49.49/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.04.04.18.57.01/test.html#lib_librumpclient_t_exec_vfork
https://releng.netbsd.org/b5reports/i386/2025/2025.04.06.03.33.51/test.html#lib_librumpclient_t_exec_cloexec

branches: 1.12.8;
PR 55338: re-enable threxec test for more test coverage.

Skip threxec test pointing at PR 55338, this kills some test beds.

Get rid of all the -lrumpdev and -lrumpvfs that are no longer needed
after moving rump's mainbus from rumpdev to rumpkern.

Produces the same atf-run results as before.

branches: 1.9.14;

Extra libs for rump.

add test case for multithreaded client calling exec

Run sockstat with -n so that difference in /etc/services don't
affect the test outcome.

branches: 1.6.2;
RUMPHIJACK_RETRY -> RUMPHIJACK_RETRYCONNECT

test rumpclient_vfork()

no need to create a hardlinked name for the helper, just fake argv[]

Don't use hijack here since exec is now easy in pure rump clients.

test FD_CLOEXEC

add some exec() tests

tests: Audit RZ abuse.

RZ succeeds if x is zero, and fails if x is nonzero, treating a
nonzero value as a error number as in errno(3) to print the message.

The following library routines instead return -1 on failure and set
errno to the error code:

fuse_opt_add_arg
fuse_opt_add_opt
fuse_opt_add_opt_escaped
fuse_opt_insert_arg
lseek
system

So use RL instead for those -- succeeds if x is zero, and fails if x
is -1.

This shouldn't make any tests newly fail or newly succeed -- the
functions in question only ever return 0 or -1 -- but if the tests
were already failing anywhere, they will now fail with meaningful
messages.

TBD: dlinfo, which isn't fit for RL or RZ since it reports errors via
dlerror() rather than errno.

fix typos in comments and one definition, mainly s/sucket/socket/.

Get rid of all the -lrumpdev and -lrumpvfs that are no longer needed
after moving rump's mainbus from rumpdev to rumpkern.

Produces the same atf-run results as before.

branches: 1.6.14;
Don't play with "../.." in includes for h_macros.h; deal with it centrally.
Minor fixes.

Extra libs for rump.

branches: 1.4.24;
t_fd/sigio: pass test if we receive at least one SIGIO signal.

While a real kernel collects these signals until the connect() returns and
then delivers one signal rump delivers every signal so we get more than one.

Ok: Antti Kantee <pooka@netbsd.org>

As the sigio test case is currently failing with "sigcnt != 1", print the
actual sigcnt value to aid in diagnosing the problem.

Add a test that checks that the client receives SIGIO for an O_ASYNC
socket.

branches: 1.1.2;
Add test which checks rumpclient does not use fds 0-2 for its
internal purposes.