3 ms·

One thing it took me a while to realize is that a lot of what's provided by "OSes", the way users think of them, is standards: ABIs, protocols, formats, etc. An

One thing it took me a while to realize is that a lot of what's provided by "OSes", the way users think of them, is standards: ABIs, protocols, formats, etc. And you can play with those in userspace. I am not saying kernels don't matter or anything, just that the kernel is not the only place one can play with radically different ways to organize stuff. So: if you want code to communicate and share capabilities through objects in a memory-safe environment, you can do that. (Browsers without strict site isolation often do this with cross-site iframes.) If you want to serialize state so you can stop and restore across reboots, you can do that. (CRIU does something like this, for apps not written for it even.) Sufficiently advanced language environments and runtimes often end up redeveloping OS-y bits (schedulers, binary formats, standard ways to exchange data). A big problem, as with completely new OSes with their own kernels and syscall interfaces, is getting people to develop to your interfaces. But it would be (is!) interesting to see folks build alternate universes in userspace that are much easier to dip into.

roryrjb 8y ago
So I believe I'm correct in saying that this is what Microsoft effectively does with WSL and Joyent does with Triton, i.e. faking a Linux kernel syscall table on top of a Windows NT kernel and Illumos kernel respectively.
- twotwotwo 8y ago
  WSL does some interesting stuff, including some new code running in kernel mode (there's more here: https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/ https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-c...). No idea about Triton. gVisor is a user-space process providing a restricted Linux interface on top of regular-old Linux via syscall interception provided by ptrace. They all certainly demonstrate decoupling the "personality" presented to app code from the original interface of the kernel. I'm trying to say something a little different, which is that lots of things conventionally thought of as OS design issues are not inherently about syscalls and ring 0, and can be (and are) worked on in userspace. Like, you can have capability-based interaction between mutually untrusted bits of memory-safe code (the model of this OS) inside a Unix or Windows process, and you can do a lot of other exploration of how to organize/format/communicate in userland. The kernel interface provides necessary tools but it's not all there is. Of course kernel-side improvement is still important; foundations matter. Just, thinking big does not only have to mean replacing or even tweaking the kernel.

roryrjb 8y ago

So I believe I'm correct in saying that this is what Microsoft effectively does with WSL and Joyent does with Triton, i.e. faking a Linux kernel syscall table on top of a Windows NT kernel and Illumos kernel respectively.

twotwotwo 8y ago
WSL does some interesting stuff, including some new code running in kernel mode (there's more here: https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/ https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-c...). No idea about Triton. gVisor is a user-space process providing a restricted Linux interface on top of regular-old Linux via syscall interception provided by ptrace. They all certainly demonstrate decoupling the "personality" presented to app code from the original interface of the kernel. I'm trying to say something a little different, which is that lots of things conventionally thought of as OS design issues are not inherently about syscalls and ring 0, and can be (and are) worked on in userspace. Like, you can have capability-based interaction between mutually untrusted bits of memory-safe code (the model of this OS) inside a Unix or Windows process, and you can do a lot of other exploration of how to organize/format/communicate in userland. The kernel interface provides necessary tools but it's not all there is. Of course kernel-side improvement is still important; foundations matter. Just, thinking big does not only have to mean replacing or even tweaking the kernel.