State of the MirageOS: an OCaml unikernel [video] | Hacker News Reader

State of the MirageOS: an OCaml unikernel [video]

irill.org

78 pointszellyn15 comments

The slides themselves (served via a unikernel) can be found at http://decks.openmirage.org/irill14-seminar#/

Very interesting content, but unfortunately bad rendering on Firefox. Better on Chrome but no scrollbars.

That's unfortunate. I just checked on firefox on my mac and I do notice a slight lag if I try to flick through slides quickly. I'm not sure what you're referring to by scrollbars though. Can you give any more detail? Feel free to email me (see my profile).

One thing I'm interested in is in Jitsu. I've tried to find more, but there is hardly anything out there. Can it do/is it easy to plugin something for load-balancing? With a 100ms boot, you could easily scale by starting VMs on the fly.

There's a paper we'll be presenting at NSDI next year on Jitsu, so there'll be more to read about soon. The repo is at https://github.com/MagnusS/jitsu

Regarding the scaling, it's definitely something we're keen to do. For example, we should be able to create hyper-elastic clouds by rapidly spinning up and culling unikernel VMs in response to demand. e.g a simple scenario might be me serving my personal blog from a cubieboard but if a post ends up on HN, then my infrastructure should automatically scale with the demand -- complete with load balancers etc and elsewhere on a public cloud provider. As demand falls, my footprint shrinks back into just the one VM on the cubieboard.

I'm sure these ideas aren't new but unikernels should make them easier to realise.

We're working on getting it cleaned up for a proper open-source release. It touches a lot of the Xen toolstack in order to reduce the serialisation latency of starting and stopping VMs.

via https://lobste.rs/s/hgknhb/state_of_the_mirage_an_ocaml_unik...

Submitted here, to get a wider audience, and ask: does anything in Rust preclude this from being done in Rust rather than OCaml? Sounds like a nice idea...

I believe several people (On both the Mirage and Rust communities) have discussed moving some or all the C code in Mirage to Rust.

If you replaced the OCaml with Rust, you wouldn't have Mirage anymore. But you could write something similar in Rust.

This video claims Mirage is pure Ocaml, so the C code may have been replaced by OCaml, but the statement still stands.

The real challenge is how much you can write in safe Rust, which is a bit of an open question. In particular, intrusive data structures are common in kernels, but tricky in Rust.

Is OCaml somehow easier for handling intrusive data structures safely? From my cursory glance, one can be pretty functional-programmey, just as in OCaml, and Rust's type system is reasonably powerful for static analysis of many things.

The OCaml module system doesn't exist in Rust, and is key to being able to fling around large abstractions with very little runtime cost.

It's worth bearing in mind that OCaml is really two distinct languages: the core ML-style language (which is concise due to type inference, and I think what the above poster is referring to by "pretty functional-programmey"), and the module language (which is verbose and signatures explicitly written down with no inference).

The latter is really the key to constructing large scale systems like Mirage, since they allow fragments of OCaml code to be mapped onto everything from Xen unikernels to JavaScript. Modules can be higher-order (that is, depend on other modules). You can read more about it at https://realworldocaml.org/v1/en/html/functors.html

It's also not yet clear how well Rust's ownership types will scale in bigger systems, but I'm sure we'll find out as the language stabilises. OCaml is a stable, fast and mature implementation of ML that has been around for years.

Nice overview of the Ocaml module system. By the way, just wanted to say thanks for maintaining the Ocaml/Opam PPA, and for keeping it so up-to-date. Has made installing and working with Ocaml much easier for those of us on Ubuntu and distros based on Ubuntu.

There are unikernel implementations in a number of other languages [1] but one of the benefits of OCaml has turned out to be the module system. I don't know much about Rust but I don't see any reason this couldn't be attempted. All the Mirage libraries are open-source [2], so taking what we've learned from these might be useful.

[1] http://deliveryimages.acm.org/10.1145/2570000/2566628/madhav... (taken from http://queue.acm.org/detail.cfm?id=2566628)

[2] http://github.com/mirage/

Personally I rather that they keep on using OCaml with the C parts rewritten in Rust.

If they are successful with OCaml, it is a win for OS low level programming in GC enabled languages.

And in the process, it helps to improve the OCaml eco-system.

This without taking into consideration that the whole MirageOS architecture is based on OCaml modules, so changing language is a bit like starting from scratch.

EDIT: typo, level was missing.

I was thinking on the same line while watching the video. Does anybody know how feasible would be to rewrite the C part in Rust?

I sometimes hack on the C part (e.g. porting Mirage to ARM). The C code in Mirage is basically:

- malloc

- printk

- openlibm (standard maths functions)

- gmp (fast big ints for crypto stuff)

- garbage collector

- support code to make the above C code compile (assert, various standard header files, etc)

Once Rust has matured, and if reliable, well-optimised replacements for all these libraries become available, then it would be interesting to use it. But until then, there isn't much C code you can replace, because there is a minimal core you need to provide to compile C libraries like gmp, and we're pretty close to that already.

Rust's linear types / lifetime support is interesting, though. For example, when you pass a buffer to Xen for transmission on the network, it's important that you don't modify it again until it has been read (or you'll get a race). Rust's type system can express that statically, whereas OCaml's can't. On the other hand, OCaml has functors, is far more mature and has lots of libraries available.

Reply on news.ycombinator.com