Investigate building a haiku unikernel

[kallisti5]

Docker, linux can run unikernel-based applications. We should investigate the potentials of offering our kernel as an ABI-compatible unikernel. This would in theory allow building our native applications under Linux, FreeBSD, Docker, etc. in unikernel runtime environments.

Resources:

• ​https://www.youtube.com/watch?v=24rvIB4_v4U
• ​http://unikernel.org
• ​https://github.com/hermitcore/rusty-hermit (Rust, Pure)
• ​https://github.com/rumpkernel/rumprun/ (NetBSD, Legacy)

Essentially, in the Linux example. The Linux kernel turns one or more SMP cores over to unikernel-based runtimes.

[marcoapc]

I hope these links help!

​https://github.com/cetic/unikernels

​https://github.com/ssrg-vt/hermitux

[kallisti5]

Thanks!

To be clear, this is a big ol' spike. I'm not sure if it would even be something we can (or should) take advantage of. However, if we offered a unikernel for Haiku, we might be able to run self-contained Haiku apps in containers

[marcoapc]

Yes, the container advantages of running standalone applications are used a lot these days.

[pulkomandy]

If I understand these things correctly, an unikernel is a way to run a single binary application inside a virtual machine. So I don't understand the relation with Docker, which is not using a virtual machine at all.

And I also don't understand how running our kernel as an unikernel would make sense, because then you have the kernel and... nothing else (since this is a single process system).

The idea of unikernels is basically to statically link EVERYTHING: the application, the C library, and the kernel into a single executable that is able to boot on a machine. You cannot have multiple processes. So you couln't use it to run app_server, registrar, net_server, etc in addition to your app? How would that be useful for running Haiku apps on Linux?

If your goal is to run Haiku apps on Linux, I don't see why you would take this approach (which requires special-compiling of basically everything) instead of either a virtual machine, or an API compatibility layer (such as our own libbe_build or something based on Cosmoe, V\OS, or Haiku-On-Genode).

[kallisti5]

If I understand these things correctly, an unikernel is a way to run a single binary application inside a virtual machine. So I don't understand the relation with Docker, which is not using a virtual machine at all.

I think this needs shifted a little. The idea is a running operating system can boot a unikernel application directly. aka, the linux kernel hands off a dedicated CPU and memory space temporarily to a unikernel binary. At that point, the binary can function fully off the ABI of the unikernel with some basic (likely virtio style?) i/o devices.

You can boot unikernel applications directly on "currently running hardware" or, you can boot them self-contained within a VM.

It's a wild concept, but represents a desire to get applications closer to bare metal. I think the most "correct" alignment is paravirtualization with the focus being offering a kernel + abi for a single application.

If we offer a command line and a base chroot, we could theoretically build applications on linux in containers, under the Haiku chroot + Haiku kernel.

[nephele]

what you describe sounds a lot like xen paravortualisation to me, and not a unikernel.

[kallisti5]

Replying to nephele:

what you describe sounds a lot like xen paravortualisation to me, and not a unikernel.

kinda? I haven't read the spec thoroughly enough. Paravirtulization doesn't work in the container model though, while unikernels do

[kallisti5]

Zen has a better overview than wikipedia:

​https://wiki.xenproject.org/wiki/Unikernels