While the rump kernel and local clients are by definition in the same
host vmspace, there are subtle differences in how in-kernel code works
in case accessing the kernel vmspace or a user process vmspace.
Problem discovered by riastradh's "read(fd, NULL, 1)" test.
instead of it being always provided by the rump kernel base. This
move accomplishes two things:
1) it is no longer necessary to provide sysproxy hypercall stubs for
platforms which do not want to use sysproxy
2) it is easier to reason about the security aspects, since configurations
not linking the sysproxy component simply do not support remote
system calls
discussed on rumpkernel-users
the separate rumpkern_time component. Keeping time-related routines
elsewhere lead to some illogical behavior if you didn't think of linking
in rumpkern_time (hands up everyone who checks the return value of
nanosleep()).
Add warnings if rumpkern_time is linked or used. I'll remove it in a
month or two instead of now since it was part of a buildrump.sh snapshot
and it's nicer if trying to use it gives a warning instead of an error
in the next snapshot.
"everything should be as modular as possible, but no more modular than that"
instead.
Include linux_socketcall.h to bring missing socket syscall
arguments/prototypes on arches that have socketcall(2).
Finally, cleanup rump linux syscall wrapper, to remove linux syscall
argument/prototype local copy.
__HAVE_MINIMAL_EMUL, we simply look up the values from p->p_emul->e_errno.
For ports which cannot afford to keep an extra pointer per emul structure
around, we hope there is __HAVE_SYSCALL_INTERN support and thread the
errno values through p_emuldata. Notably, we cannot alter the syscall
method like most ports do with syscall_intern, since they do it via
p_mdproc, so MI code is not possible there.
