3 ms·

Glad to see a hypervisor-generic way of doing unikernels is advancing. I never liked to tie in with Xen (or another hypervisor) when building an app as a uniker

by cies 11y ago

Glad to see a hypervisor-generic way of doing unikernels is advancing. I never liked to tie in with Xen (or another hypervisor) when building an app as a unikernel.

avsm 11y ago
The interesting thing about the unikernel approach that we're discovering is how useful the portability of the resulting applications is. Because everything is structured as a graph of libraries, only a little modification can pull in a huge amount of useful functionality. For instance, Martin's work on Rump+Mirage now pulls the whole safe OCaml stack into a bare metal environment: the type-safe TCP/IP, HTTP, TLS, DNS libraries can all be deployed onto any target supported by NetBSD/Rump -- which includes some pretty small embedded ARM devices that we couldn't boot on before due to the Xen requirement! On the other side of the spectrum, Thomas Leonard has ported a good chunk of the MirageOS stack to JavaScript, and built browser applications using the Irmin Git datastructure library: http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-things-done-in-the-browser/ http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-t... We're working hard on getting all these pieces upstreamed at the moment, so it's not quite ready for primetime yet (the bare metal stack still has no network driver ported), but it's rapidly all coming together. I'm excited!
- pjmlp 11y ago
  Any idea to replace the existing C bits by Rust now that 1.0 is out? I remember seeing some post related to that as possible scenario.
anttiok 11y ago
Not only a hypervisor-generic, just generic. Whoever said that unikernels required the cloud wasn't thinking too much </friendlyjab>. I share avsm's excitement, and think we're on the verge of a transition away from the world where the OS is some arbitrary black box that you must have for anything to work. In the future world the components included in software stacks are determined per application need instead of the OS author('s ego). That transition is partly motivated by the cloud, but also partly by more and more smaller and smaller special-purpose devices.
- mwcampbell 11y ago
  I think the reason why unikernels are typically associated with virtualization is that nobody these days would want to dedicate a whole computer to a single task. Even the cheap ARM SBCs (Raspberry Pi, Cubieboard, etc.) are capacious enough for a full multitasking OS or hypervisor, and the Mirage stack is probably too big to run on microcontrollers. In what situation would it be useful to run a unikernel on bare metal, without a hypervisor or multitasking OS underneath it?
  - anttiok 11y ago
    Let's assume that a consumer device vendor does not want to pay more for hardware than what is required by their application. It's an assumption, but I think it's a fairly reasonable one to start from. So the game boils down to "required by". For any non-trivial application (larger than x kB microcontroller) running on non-trivial hardware and using non-trivial software constructs you need non-trivial drivers. Those non-trivial drivers have to come from somewhere. That is the reason why OS's are scaled down (i.e. hacked to pieces) to fit the embedded market. When you start looking at constructing the software stack from the perspective of the requirements of the application, not those of the OS, you can leave a huge amount of gunk out since you know precisely what you will need. Why wouldn't you build your software stack to consume only the necessary amount of resources?

by cies 11y ago

Glad to see a hypervisor-generic way of doing unikernels is advancing. I never liked to tie in with Xen (or another hypervisor) when building an app as a unikernel.

avsm 11y ago

The interesting thing about the unikernel approach that we're discovering is how useful the portability of the resulting applications is. Because everything is structured as a graph of libraries, only a little modification can pull in a huge amount of useful functionality. For instance, Martin's work on Rump+Mirage now pulls the whole safe OCaml stack into a bare metal environment: the type-safe TCP/IP, HTTP, TLS, DNS libraries can all be deployed onto any target supported by NetBSD/Rump -- which includes some pretty small embedded ARM devices that we couldn't boot on before due to the Xen requirement! On the other side of the spectrum, Thomas Leonard has ported a good chunk of the MirageOS stack to JavaScript, and built browser applications using the Irmin Git datastructure library: http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-things-done-in-the-browser/ http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-t... We're working hard on getting all these pieces upstreamed at the moment, so it's not quite ready for primetime yet (the bare metal stack still has no network driver ported), but it's rapidly all coming together. I'm excited!

pjmlp 11y ago
Any idea to replace the existing C bits by Rust now that 1.0 is out? I remember seeing some post related to that as possible scenario.

anttiok 11y ago

Not only a hypervisor-generic, just generic. Whoever said that unikernels required the cloud wasn't thinking too much </friendlyjab>. I share avsm's excitement, and think we're on the verge of a transition away from the world where the OS is some arbitrary black box that you must have for anything to work. In the future world the components included in software stacks are determined per application need instead of the OS author('s ego). That transition is partly motivated by the cloud, but also partly by more and more smaller and smaller special-purpose devices.

mwcampbell 11y ago
I think the reason why unikernels are typically associated with virtualization is that nobody these days would want to dedicate a whole computer to a single task. Even the cheap ARM SBCs (Raspberry Pi, Cubieboard, etc.) are capacious enough for a full multitasking OS or hypervisor, and the Mirage stack is probably too big to run on microcontrollers. In what situation would it be useful to run a unikernel on bare metal, without a hypervisor or multitasking OS underneath it?
- anttiok 11y ago
  Let's assume that a consumer device vendor does not want to pay more for hardware than what is required by their application. It's an assumption, but I think it's a fairly reasonable one to start from. So the game boils down to "required by". For any non-trivial application (larger than x kB microcontroller) running on non-trivial hardware and using non-trivial software constructs you need non-trivial drivers. Those non-trivial drivers have to come from somewhere. That is the reason why OS's are scaled down (i.e. hacked to pieces) to fit the embedded market. When you start looking at constructing the software stack from the perspective of the requirements of the application, not those of the OS, you can leave a huge amount of gunk out since you know precisely what you will need. Why wouldn't you build your software stack to consume only the necessary amount of resources?