On 10/08/15 21:26, Robert Millan wrote:
If you want more, look at syscall compat (full, automated translation)
Please forgive my ignorance, but I'm not sure what you mean by syscall
compat. Could
you point me to some document and/or source file to look at?
Syscall compat is like COMPAT_FOO in NetBSD. It translates the args of
FOO to NetBSD and the results back. In the case of normal NetBSD,
syscall compat allows running FOO binaries on NetBSD. For rump kernels,
it allows rump kernel system calls made from FOO userland to work
against rump kernels as-in, e.g. calling rump_sys_stat() with a host
"struct stat" will work. Substitute FOO for e.g. LINUX, and you
probably get the idea.
Look at libsys_* in src/sys/rump/kern/lib.
The only downside is that the semantics turned out to be really hard to
figure out. Currently, if you link a libsys_foo against a rump kernel,
_local_ client syscall will use the translation (linking multiple
libsys_foo is bad). Remote ones will not simply because we couldn't
figure out sensible semantics. For example, if a remote client
automatically gets a syscall vector for its host, what do you do if you
want some remote client to make native calls not covered by the compat
vector (e.g. mount()). Would it be secure to allow for native and
non-native syscalls for the same process (talking about the rump
kernel's idea of a process, of course)? Notably, the previous is not a
security issue for local clients because, well, they're local. If
you're really interested in some specific, I might be able to find to
more details of the semantics woes from some old private emails with
Arnaud (they predate the existence of this list), but I don't want to
spend effort for digging for a "yea sure why not".
