(and especially, after filesystems have been unmounted).
This way, rump.halt returns once the rump kernel is really out of the
game, which avoids races issues in test scripts using a rump kernel.
OK pooka@
returning directly. This allows other threads to run possible
setting a condition we are waiting on.
Fixes a busyloop condition which could be entered from vfs_unmountall()
where we were waiting for vrele_pending and the vrele thread could
not run since we were hogging the CPU.
should generate the right info, but it's easier to fix here now.
This fixes compat syscalls for rump servers with dynamically loaded
components. Since the compat syscall revamp a little time ago e.g.
stat() didn't work on my system (which is 5.0-based) with e.g.
rump_server -lrumpvfs. Static servers and non-compat syscalls
worked just fine, though, making this a little harder to spot that
the usual bug.
in the socket before we shut down. This way the response to the
syscall travels to the caller and they know things worked correctly
instead of having to just assume.
necessary for rump.
XXX: strictly speaking, the zfs implementation does not work
correctly since it just wakes up a thread instead of performing
the scan in the context of the pagedaemon
if it has enough memory available, just pick a number which makes
zfs happy.
We *could* use a MIN() of available host mem and rump_memlimit,
though ...
some locking and rumpcopy primitives and refactor module building Makefiles
to work with both RUMP and kernel modules. This is first part of adding
support for regular test of zfs on NetBSD to hunt some bugs and make it
stable.
Ok by pooka@.
threads blocking in the kernel automatically exit when the process
exists. However, for the sysproxy case this does not hold.
Typically it's ~harmless, but e.g. in the case of socket binding
following by poll it gets annoying.
Introduce sysproxy procexit, which wakes up all threads blocking
on a condition when a process's communication socket is closed.
The code is a little different from the regular kernel simply
because in a rump kernel l_mutex is not available at all times
(this is because scheduling happens on every kernel entry and exit,
and that path must be kept lockless for any reasonable performance).
Instead, use gating which makes sure all threads are either out of
the cv code or suspended in a well-known state. Then, wake up the
threads and tell them to get the hell out of our galaxy.
It is executed after IF and the purposes to guarantee the right
order in cross-component interface address configuration.
(e.g. lo0 is attached by net but 127.0.0.1 is configured by netinet)