Comment by justmarc
1 year ago
It's a lot "simpler" to support a Linux userland as that means one needs to "just" emulate all the Linux syscalls, than to implement the literally countless internal APIs needed for drivers etc, as that would otherwise mean literally reimplementing the whole Linux kernel and that's neither realistic, nor too useful.
And that’s not all that simple, as has been experienced by Solaris (never released(?) Linux branded zones, illumos (lx brand), and Windows (WSL1) developers that have tried to make existing kernels act like Linux.
It’s probably easier if the kernel’s key goal is to be compatible with the Linux ABI rather than being compatible with its earlier self while bolting on Linux compatibility.
I'm sure it's not trivial, but I was under the impression that illumos, FreeBSD, and NetBSD all have perfectly good Linux compatibility layers so it's clearly doable. (WSL1 excepted because NT apparently really doesn't want to be a unix-like)
From my experience working on it from time to time at Joyent, the parts that are implemented work pretty well on the lx brand in illumos. At the time, things like cgroups and namespaces were not implemented and there was no clear path to implement them. It’s kinda hard to participate in the docker or k8s ecosystem with such limitations.
I was hired at Joyent largely to work on bhyve so that Triton and Joyent’s public cloud had a way to run Linux VMs when full Linux compatibility was more important than the efficiency of zones/containers.
> emulate all the Linux syscalls
and emulate the virtual filesystems (/proc/...)