two or more syscall requests before any worker thread ran, we might
not have enough threads to handle the requests. In some scenarios
this could lead to a deadlock.
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.
* don't hold spc mutex while sending data
* use send() for the banner to avoid SIGPIPE in case a client
connects and immediately goes away
* fix error path locking
* use kevent() instead of pollts() in the client. Apparently that
is the only sensible way for a library to support both multithreading
and signal-reentrancy in a race-free manner.
(can I catch all signals with one kevent instead of installing
NSIG different ones??)
* mark client comm descriptor non-blocking so that clients have
better signal-interruptibility (we now sleep in signal-accepting
kevent() instead of signal-masked recvfrom())
requests which have a 0-length response (such as copyin 0/0).
This change makes links(1) work against a rump kernel which contains
rumpnet_local. The presence of unix domain sockets caused links
to select() with 0 fds and a timeout, and because copyin never woke
up in the kernel the application blocked indefinitely.
violent disconnect. Fixes some race conditions (maybe the one
occasionally showing up on tests/rump/rumpkern/t_stress).
thanks to schmonz for some discussion
It's pretty much a placeholder for now. One plan for the future
is to require some sort of authentication for superuser clients.
The code will need a little massage then, though, to prevent DoS
attacks.
limits. This improves syscall throughput about 2x for non-userio
syscalls (no copyin/out, e.g. getpid()) and almost 1.5x even for
things like __sysctl().
(measured for cases where the remote process is on the local machine)
XXX: if the pthread deadqueue sucks for anything which cares about
performance, why does it exist? Nuking it would make supporting
variable stack size easier.
==> add support for remote vmspace vmapbuf/vunmapbuf
==> add proper support for copyin/out_vmspace
==> add support for remote vmspace uvm_io
==> add support for non-curproc rumpuser_sp_copyin/out
==> store remote context in vm_map->pmap instead of
pthread_specificdata
In short, makes read/write of most (all?) block devices work from
a remote rump client via rump syscalls.
basics are there, but a few more tweaks are needed. The reason
I'm committing it now is that the code was mindnumbingly boring to
write (no wonder it took me almost 3 years to get it done), and I
might burn it if it's not in a safe place.
This incarnation is written in the user namespace as opposed to
the previous one which was done in kernel namespace. Also, rump
does all the handshaking now instead of excepting an application
to come up with the user namespace socket.
There's still a lot to do, including making code "a bit" more
robust, actually running different clients in a different process
inside the kernel and splitting the client side library from librump.
I'm committing this now so that I don't lose it, plus it generally
works as long as you don't use it in unexcepted ways: i've tested
ifconfig(8), route(8), envstat(8) and sysctl(8).
