OCaml and Mirage now running on rumprun, including bare metal | Hacker News Reader

OCaml and Mirage now running on rumprun, including bare metal

freelists.org

81 pointsbcg110 comments

This will be extremely useful for running on very small devices (not all ARM boards have the virtualisation extensions that are needed to run Mirage unikernels as Xen VMs).

But it also looks like lots of progress has been made with cross-compilation support in the OCaml compiler too. At the moment, I compile my Xen unikernels on my Cubieboard, but it would be quicker to cross-compile to ARM on my laptop and just push the final VM image.

What small devices do you have in mind? True, the Raspberry Pi doesn't support virtualization, but in that case, you can run Mirage applications as normal Unix processes on Linux or FreeBSD, using raw sockets.

I was thinking about smaller devices than the Pi. Security devices, monitors, IoT type stuff. Especially where you want to minimise the amount of C code running and know exactly what it's doing.

I think it's also fun from a hobbiest point of view to do useful things without a traditional OS (Xen still requires Linux or similar in Dom0), but instead using a safe high-level language for most of it.

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.

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-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!

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.

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.

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?

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?

So rumprun allows you to run rump with the NetBSD lowlevel bits included getting a baremetal image where the highlevel parts target rump. Is that what this is and does that limit hardware support to NetBSD drivers and supported architectures?

Reply on news.ycombinator.com