

OCaml and Mirage now running on rumprun, including bare metal - bcg1
https://www.freelists.org/post/rumpkernel-users/OCaml-and-Mirage-now-running-on-rumprun-including-bare-metal

======
talex5
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.

~~~
mwcampbell
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.

~~~
talex5
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.

------
cies
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
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...](http://roscidus.com/blog/blog/2015/04/28/cuekeeper-gitting-
things-done-in-the-browser/)

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

------
cm3
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?

