POSIX/Linux emulation layer
There are two modes for this: Linux ABI-compatible and recompile-with-robigo-libc.
We should see how we might be able to structure the code to share the implementation of syscall handling between the two solutions.
We might look into implementing the Robigo support services themselves by having a different service for each linux namespace, which either implements namespace-specific syscalls directly or provides objects that implement them.
Linux ABI-compatible
We'll need to implement a Linux compatible ELF loader. Linux-emulated processes wouldn't have any seL4 caps, and have a handler that translates the Linux syscall to a Robigo request installed at the fault endpoint. seL4 syscall numbers are negative, and Linux syscall numbers are positive, so this will likely work out well in practice. Since Linux threads won't have any caps, there's no need to worry about accidentally invoking an object.
Recompile with robigo libc
This option is much more liberal - it's a regular phoma process, but calling certain libc functions will send out a Robigo request. The process is allowed to do both regular phoma operations and POSIX operations. Our libc, based on musl, will re-implement __syscall to make Robigo requests instead of trapping into a kernel.
Could look at midipix for inspiration here.
We may look into optimizing this solution in the future by implementing more functionality beneath the syscall emulation layer.
Comments from sorear from IRC discussion:
if you have enough functionality at the "syscall" level that you can disable all of musl's SIGCANCEL and SIGSYNCCALL code you will be much happier
a lot of it is extremely pointless own goals like "POSIX defines setuid() to be per-process, but Linux defines it per-thread, so libcs handle setuid() by installing an invisible signal handler, maintaining a shadow list of threads, and signalling all threads to change UID separately"
if you can provide a mechanism outside of the process that changes all threads simultaneously, and a few similar things, you can get rid of the shadow thread list, which has huge simplicity benefits in the thread li