[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] OCaml and Mirage now running on rumprun, including bare metal

On 24/05/15 16:41, Anil Madhavapeddy wrote:
Good show!  Supporting existing platforms and applications while
enabling things to be done better where it matters most is a true
realization of the rump kernel slogan "you can make an omelette
without breaking the kitchen".

That said, can you expand on the motivations behind your work with a
paragraph or so?  I don't recall the project being introduced at
least on the rump kernel kernel list, and I while can guess the
motivations, I'd rather not guess if I don't have to ;)

The Mirage folks have built a green-field implementation of a TCP/IP, TLS
and HTTP stack, all in memory-safe OCaml. What I'd like to get to is
being able to build systems which use the best of both worlds. For example,
have a Mirage unikernel serve TLS and/or HTTP, and talk FastCGI to a PHP
backend running on a rumprun unikernel.

The other interesting aspect is using Jitsu [1] to spawn just-in-time
unikernels on demand. This would let you have a bunch of unikernels which
are dormant and are only booted when the service they provide is actually

The other reason that this is so useful is that it opens up the other
non-Xen backends to Mirage (such as KVM) in the short term.  In the longer
term, we'd replace the virtio drivers with type-safe equivalents, but its
useful to be able to boot on KVM with the Rump drivers to get started
and have a stable point.

In general, the mixing of new type-safe drivers in Mirage/HaLVM and
newer languages such as Rust, combined with the stable Rump NetBSD drivers
is a pretty compelling way to migrate towards unikernels...

This other reason is the one I see as the extremely interesting one. It's curious, the longer the current implementation provided by rump kernels (*) stays useful, the more disappointed I am since we have failed to provide better options to legacy software. That said, even with newer languages existing, I will be extremely surprised if the current implementation will be obsolete in 10 or even 20 years -- the Tarzan who rewrites everything in safe languages in production quality simply doesn't exist. I do hope people try to prove me wrong, though either way I win: either I'm right, or I have vastly better software at my fingertips.

For users, these types of synergies are truly exciting: being able to ride the wave of the latest omelette research while at all times having access to a fully equipped, working kitchen. Getting more users and deployers on board also gives us good feedback on which reality-derived problem/component is currently in most urgent need of a solution.

*) the concept is generic, and I hope that future operatin^Wbottom layers of the software stack will retain separation between driver implementation and the environments the driver is usable in.

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.