Hi Antti,
El 11/08/15 a les 01:17, Antti Kantee ha escrit:
On 10/08/15 21:26, Robert Millan wrote:ng
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 diggi
for a "yea sure why not".
