Due to the nature of the feature under test, this one is a little
different, so let me explain how it works.
The test program forks and bootstraps a rump kernel in both processes.
It then configures shared memory interfaces in both. shmif is nice
in that it uses a mmaped file as the bus and does not require root
privileges for communication between two (or more) processes. The
child process then proceeds to increase icmp.returndatabytes as
indicated by the PR, while the parent process sets the global TTL
of the rump kernel to 1 (note: both values only affect the respective
rump kernels, not each other or more importantly the host kernel).
The parent then sends the bad packet which is supposed to be routed
by the child. If ip_icmp.c was too old, *boom* + fail; otherwise
nothing bad happens and the test exists with success after one
second.
Eventually this test can be extended into a framework for automated
testing of any networking code which requires (arbitrarily complex)
routing setups.
get tmpfs rename to "tstile".
Note1: triggering this on any non-SMP system is not as easy (because
one system call tends to run from start to finish in one go) and
therefore I've limited it to i386 and amd64. Incidentally, I'm
still waiting for the eternally elusive MI CPU_INFO_FOREACH (or at
least something else than a stupid macro) ...
Note2: this is a "race condition" test. I tested it on my development
host and in qemu and it triggers pretty instantly. But YMMV.
/null/dev: we're interested in /dev/pts and nullfs doesn't traverse
underlying mountpoints.
(I had code for nullfs mountpoint traversal in the tree i used to
test this originally... but I assume the rest of the world doesn't.
Before this change the test would still fail, but fail in the wrong
place and due to the wrong reason.)
* RUMP_MEMLIMIT works
* allocating memory with PR_NOWAIT will fail immediately if no memory
is available and PR_WAITOK will wait for memory to be available
in non-routed setups b) avoid the dubious security implications.
Also, to make the test actually do what it claims to do, call
getsockname() and verify we got a low port.
Note: I'm not adding these to the build yet, since they depend on
some other other cleanup I might get done only after the weekend.
Even so, t_nullpts serves a simple example of how to repeat the
crash described in PR kern/43456 (just remove "rump_sys_" from the
calls and it should compile and you should get a host kernel panic
instead of a coredump).
such as the one used by "anita test".
This has also the added benefit of decoupling the tests from whataver
is in "words", should that file ever be updated.
/stand/arch/vers/kmods works in rump (and that the result is usable ;).
On i386 this "just works". For amd64, due to -mcmodel=kernel,
things are a little more complicated. We must have the entire rump
kernel loaded in the lower 2GB. Currently, this can be done either
by using the non-PIC version for the rump kernel compiled with
-mcmodel=small, or, as njoly pointed out, using netbsd32, which
causes vm_default_addr() to give something in the lower 2GB and
therefore shared libs "magically" getting loaded there. I guess
it would be possible to put a suggested vaddr into the rump kernel
libs and make ld.elf_so map memory from the suggested address if
present ... but that's another show.
Also thanks to tron for access to an amd64 so that I could verify
the test works.
going to whitewash the test failures, we should at least keep track of
what the "real" correct behavior/output is. Especially since a large
portion of the tests in here were added specifically to illuminate
points at issue in prior discussions.
their work directory. The purpose is to be able to know which tests intend
to touch the file system and to allow a minor optimization in atf-run.
Define use.fs=true for all those tests requiring it. (This highlights that
some tests currently require modifying the file system but conceptually
they shouldn't be... which leaves room for further improvements/cleanups
later :-)
the ffs test because msdosfs doesn't support VFS_SNAPSHOT, only
VFS_SUSPEND, i.e. we need external storage for the snapshot instead
of internal storage.
I really wish all our fs tests were like this (in principle, that
is. I'm not talking about this hacky implementation). I've been
wishing this for quite a few years now. Seems like my wishes don't
come true.
same as with the kernel module (and hence MOUNT_NULL).
I added the old name to the obsolete list, but given that it was
in-tree for only a bit over a week, I'll remove the entries in a
few weeks.
XXX: the reverse mapping case (last subsubtest in t_basic) does
not make any sense, but apparently that how umapfs works. I'm not
familiar enough with the code to determine if this is a wanted
feature or a pure and simple bug.
subcommands and the optional argument passing to them from the command
line.
Triggered by the modification of the run_rc_command function in rc.subr
to allow passing in extra parameters to the commands defined in rc.d
scripts.
the LDADD variable expansion. To support static linking, ensure
that the common libraries gets tacked on at the end as well (order
matters for static linking), by using a convenience variable and
add it to the end of LDADD.t_modlinkset, as well as when doing the
general LDADD+= setting.
