Claiming that they've "implemented" 42 syscalls seems like an overstatement: almost everything is a stub that does nothing, and the bits that are implemented are not even close to being half-baked. Even relatively easy stuff like dup is missing.
That said, 42 is not enough to run a lot of applications.
It'll be interesting to get to the point where they can run a language's runtime or unit tests.
Take it from someone who worked on gVisor: this is gonna take a long time, and eventually you'll end up with a system that's just Linux. You'll end up either being bug-for-bug compatible, which means bringing in loads of compatibility code and architecting your kernel just like Linux, or you'll end up having to change applications (and then you're not all that compatible anymore).
Neither are fun or sustainable compatibility stories. You'd probably actually get Linux apps to work on a random OS faster & nicer by porting gVisor.
> Moreover, since implementing a system call is typically pretty simple [...]
You're in for a fun ride, folks.
That said - why do you have to get musl compatibility by implementing the Linux syscalls? Is contributing to musl an option?
Wrt. to why we have to implement Linux-like syscalls; Musl is written specifically for Linux so in order to "unlock" the relevant POSIX-bits that Musl can provide we have to provide the underpinnings that Musl requires.
I'm hoping we can upstream some of our non-intrusive changes to Musl. However since Musl has a very specific purpose (a Linux-specific C and POSIX library) I'm not certain that our changes are within the scope of the project. To date we've only concerned ourselves with a small subset of Musl and only on amd64.
I don't think we need to run everything. I think we'll be happy if we can take some common libraries and compile them and they work. That is currently our goal. Down the road, depending on interest, we can perhaps expand a bit.
>> Moreover, since implementing a system call is typically pretty simple [...]
> You're in for a fun ride, folks.
Thanks for the heads up. It was meant as opposed to implementing the syscall and layers on top of it.