Linux compatibility in IncludeOS
includeos.org
Linux compatibility in IncludeOS
1–10 of 36 posts
Re: Linux compatibility in IncludeOS
#2I'm pretty ignorant on Unikernels so maybe there's another solution, but not being able to `fork()` is a significant problem for many applications.
Re: Linux compatibility in IncludeOS
#3Claiming 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.
Re: Linux compatibility in IncludeOS
#4If you're into unikernels, rumpkernels[0] are the least-modification-required approach I've seen.
Basically, if you compile your program with a minimally (as minimal as is possible) modified compiler, you get "rumprunnable" output. there's a list of popular packages built to run on rump kernels[1] (Rust is supported[2]). I haven't tried to use the toolchain yet, but it's pretty appealing to me.
The biggest issue is that rumpkernels seem to not be in developed anymore. I can't tell if the entire is just off somewhere being productive with their rumpkernels and are happy or if no one is around at all. The Github organization[3]'s repos all seem to not have been changed in a while either.
Outside of rumpkernels, Nabla containers[4] also look interesting to me. They're built on Solo5[5], but the only microkernels on there are currently MirageOS (for OCaml) and IncludeOS (C++?). Nabla looks amazing (containers look like a great fit and they seemed to have improved ergonomics massively), but the limitations[6] are intense.
[0]: https://github.com/rumpkernel/wiki/wiki/Info:-FAQ
[1]: https://github.com/rumpkernel/rumprun-packages
[2]: https://github.com/rumpkernel/rumprun-packages/tree/master/r...
[3]: https://github.com/rumpkernel
[4]: https://nabla-containers.github.io/
Re: Linux compatibility in IncludeOS
#5There’s a lot to like here.
1. Focusing on compatibility is smart because it’s the weak point of IncludeOS and other unikernel projects.
2. Musl is an incredibly underrated project and I hope one day it becomes the new standard libc.
This is just a first stab, but it could turn into something great.
I wonder if gvisor and includeos could be combined in interesting ways, or at least steal from each other’s code and ideas?
Re: Linux compatibility in IncludeOS
#6I'm pretty ignorant on Unikernels so maybe there's another solution, but not being able to `fork()` is a significant problem for many applications.
My understanding is that unikernels are single-application by design. I agree that a mechanism to spawn other apps is useful, but in this case it won't be a simple fork but the creation of a complete new os instance.
Re: Linux compatibility in IncludeOS
#7I'm pretty ignorant on Unikernels so maybe there's another solution, but not being able to `fork()` is a significant problem for many applications.
On Unix you typically fork as a part of initializing your application in order to demonize. Or when you are executing another program so a fork/exec.
The first one isn't needed in a unikernel. You are already demonized when you boot up.
The second use is not available to unikernel applications. The limitation of a single application per vm applies.
Re: Linux compatibility in IncludeOS
#8Claiming 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.
The number of system calls says close to nothing of the actual API surface present here. It's a poor measure. What actually matters is: what can I run?
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.
Re: Linux compatibility in IncludeOS
#9Claiming 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.
The number of system calls says close to nothing of the actual API surface present here. It's a poor measure. What actually matters is: what can I run? 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 sys…
Given what I just read about IncludeOS (I'm not really familiar), it feels like implementing as much of musl as possible is probably the best you can do compatibility wise. There are going to be a lot of Linux features simply incompatible with includeOS, so claiming that 400 syscalls will be implemented is unlikely.
That said - why do you have to get musl compatibility by implementing the Linux syscalls? Is contributing to musl an option?
Re: Linux compatibility in IncludeOS
#10Claiming 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.
The number of system calls says close to nothing of the actual API surface present here. It's a poor measure. What actually matters is: what can I run? 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 sys…
[deleted]