what would it take to implement user mode linux (where syscalls are... stubbed from what I can tell? no... that's not right. where hardware is virtualized/mocked? i don't know the right terminology) for something like Mac OS X (arm64/aarch64) so that Mac users could benefit from "containerization" in a hipster way
You probably want to take a look at gVisor[1], there's some desire for it to work on other systems like macos[2]. It doesn't have a working solution there yet but it's probably the easiest way to make something like Microsoft's WSL1 which handled things that way. You'll get a lot of the boiler plate out of the way that you'd need to pretend to be a Linux system, and just have to implement the translations to MacOS calls through some kind of library. From the looks of the github thread it seems the main issue to doing it is cgroup support since there isn't anything similar to it on the other side.
The Linux kernel API is so complex, and so ill-specified, that the only practical way that would maintain userspace compatibility would be to run the Linux kernel itself under macOS. (Microsoft tried to implement the Linux API in NT with WSL 1 and they abandoned that approach in WSL 2 because, among other reasons, it was just too much work to achieve Linux compatibility.) Running the Linux kernel under macOS can be done with Apple's hypervisor framework.
> they abandoned that approach in WSL 2 because, among other reasons, it was just too much work to achieve Linux compatibility
Any particular citation for this claim? I tried to do some searching and couldn't find anything definitive, but my memory from contemporaneous conversations and articles suggests that the primary reason was really performance, since the differences in how filesystem access in particular work between Windows/Linux were such that some of the I/O bottlenecks were deemed too difficult to impossible to address.
Certainly WSL2 has higher compatibility, but I'm not sure that compatibility and not performance was the primary driver, and would love a source if you have one.
Relatedly, it's worth noting that a number of other platforms have developed and shipped syscall translation layers for Linux binaries, including FreeBSD and SmartOS/illumos.
> Our top requests from the WSL community have been to increase the file system performance, and make more apps work inside of WSL (i.e: introduce better system call compatibility). We have heard your feedback, and are glad to announce that WSL 2 helps solve these issues.
> In WSL 1 we created a translation layer that interprets many of these system calls and allows them to work on the Windows NT kernel. However, it’s challenging to implement all of these system calls, resulting in some apps being unable to run in WSL 1. Now that WSL 2 includes its own Linux kernel it has full system call compatibility.
The WSL2 architecture video lists two motivators from WSL1 based on number of Github issues. One of them being file performance and the other syscall compatibility with some specific examples being the ptrace syscall and Docker compatibilty.
https://youtu.be/lwhMThePdIo?t=755
I believe this is actually one of the ways that Docker actually implements things for their MacOS support, so it's already done for containerization type stuff. Though I don't believe that docker gives you any real access to the "host" that is sets up for doing this.
> that the only practical way that would maintain userspace compatibility would be to run the Linux kernel itself
Meanwhile, Google Container Engine uses gVisor, where the syscalls are implemented by some Go libraries with a very narrow seccomp interface to the actual host.
Not quite, UML is the linux kernel ported to be an executable that runs under Linux. It's design kind of requires the system calls from Linux to be able to run properly. Making a translation layer for that isn't impossible but it would add more overhead to running things that way. Running a VM in a hypervisor, you're instead creating a whole virtual computer and its IO interfaces instead of at the system call level. Because there's hardware support for doing that virtualization (basically the CPU can help isolate the new process so that it can't see real hardware and the hypervisor gets notified/pulled in when needed to emulate the IO) it can end up nearly native speed if setup correctly.
> Not quite, UML is the linux kernel ported to be an executable that runs under Linux. It's design kind of requires the system calls from Linux to be able to run properly.
How large of an effort would it be to make it work on Mac? Monstrous? Not that bad? 100 hours? 1000 hours? For what payoff?
FreeBSD has a syscall compatibility layer for Linux: https://wiki.freebsd.org/Linuxulator. As noted by other people, Windows used to have such a compatibility layer as well, but they've moved away from it newer versions.
