3 ms·
I hate to be that guy that's clearly ignorant on a particular topic, asking "why not just do <extremely hard or nonsensical thing>?" but I've always wondered..
by seabrookmx 3y ago
I hate to be that guy that's clearly ignorant on a particular topic, asking "why not just do <extremely hard or nonsensical thing>?" but I've always wondered..
Why can't you just make a Linux kernel module that takes an arbitrary ELF and runs it in kernel space? This is identical to what unikraft describes doing only with their own kernel. We have firecracker starting full Linux very quickly these days.. no more worries about missing syscalls, drivers, weird scheduler behavior etc? It would be just like running your app as a Linux process but sans the constant hops from ring 0 to 3 and back.
- paulddraper 3y agoDo you want your container to interact with any other things? (e g. filesystem, local network, debugging tools?)
- seabrookmx 3y agoOf course. But you can already do all of those things from kernel space, even if the developer experience is different.
- tzakrajs 3y agoyou could just as easily make it pid 1 and call it a day
- seabrookmx 3y agoWell that's not a unikernel though, and is basically what firecracker-containerd does. You still have to traverse the syscall boundary which has a performance hit.
- nderjung 3y agoHi, author here, You can, and we've written about the differences also, here [0]. The summary is that there is still a performance hit for boot time (100s of milliseconds to seconds vs. 1 to 100 of milliseconds for Unikraft); performance hit at runtime (even removing the syscall boundaries has a less-than-ideal impact based on previous studies); and, there's extra bloat from the image size itself (the image is still at the very least 30MB+ vs. as little as 100KB for Unikraft) which affects startup time and cost of storage + transport. [0]: https://unikraft.io/blog/ukl-vs-unikraft https://unikraft.io/blog/ukl-vs-unikraft
- seabrookmx 3y agoNeat! Thanks for this.