
The Solo5 Unikernel - ingve
https://github.com/djwillia/solo5
======
marssaxman
There's a lot of activity going on in this space right now, which is great. I
was working on my own project very similar to this one, which I called
'fleet':

[http://www.github.com/marssaxman/fleet/](http://www.github.com/marssaxman/fleet/)

I've recently decided to stop working on this and to start contributing to
IncludeOS instead, since they have a lot of energy and good ideas, and they're
getting farther than I was on my own:

[http://www.github.com/hioa-cs/IncludeOS/](http://www.github.com/hioa-
cs/IncludeOS/)

One great thing about unikernels is that fragmentation is not really a
problem: it's a good thing to have a healthy, diverse ecosystem of unikernel
libraries adapted for different purposes.

~~~
amirmc
> _" One great thing about unikernels is that fragmentation is not really a
> problem: it's a good thing to have a healthy, diverse ecosystem of unikernel
> libraries adapted for different purposes."_

I agree with having a diverse set of libraries but we need to take care that
we solve _common_ problems in a consistent way. For example, passing config
parameters into unikernels, how they get deployed to common cloud platforms
and even how we monitor and log activity. For unikernels to become mainstream,
we need to ensure we don't fragment _this part_ of the toolchain (silos won't
help adoption). It's part of why
[https://devel.unikernel.org](https://devel.unikernel.org) exists -- to share
solutions and converge on tooling.

------
amirmc
There's an introductory blog post at [https://mirage.io/blog/introducing-
solo5](https://mirage.io/blog/introducing-solo5)

(And a new discussion site for unikernel development at
[https://devel.unikernel.org](https://devel.unikernel.org))

------
gdamjan1
from the [https://mirage.io/blog/introducing-
solo5](https://mirage.io/blog/introducing-solo5)

> So far I've found that generating a bootable iso with GRUB as a bootloader
> and relying on QEMU to emulate BIOS calls to load the kernel is, by the
> nature of emulation, inefficient and something that should be avoided.

afaik, loading the unikernel directly with `qemu -kernel` avoids that?

~~~
djwillia
> afaik, loading the unikernel directly with `qemu -kernel` avoids that?

(author here)

Thanks for this. I believe you are correct, though I have not yet had a chance
to benchmark it.

It seems like there are a few different "shortcuts" that pre-load the kernel
into memory (like `qemu -kernel`) from different tools. For example, I know
also of `kvmtool` used in the clear containers project[1].

I'm not sure if all of them choose multiboot[2] as their standard and it's not
clear how much of a traditional boot could or should be pushed into the
hypervisor. `kvmtool` prepares a 64-bit environment with the Linux "zero page"
structure instead of multiboot.

From a unikernel perspective I think this is an interesting question to ask,
because typical CPU setup including page tables (direct map is common for such
a simple kernel) and segment registers, etc. will likely all be boilerplate.
It will almost certainly be faster to preload the CPU and memory than to do it
at boot time. (At the cost of reducing the number of hypervisors that can boot
the kernel)

[1]: [https://lwn.net/Articles/644675/](https://lwn.net/Articles/644675/) [2]:
[https://www.gnu.org/software/grub/manual/multiboot/multiboot...](https://www.gnu.org/software/grub/manual/multiboot/multiboot.html)

------
nickpsecurity
Interesting project. I'm curious why he called it Solo5 in case I've seen what
inspired it.

