

State of the MirageOS: an OCaml unikernel [video] - zellyn
https://www.irill.org/videos/oups-december-2014/MirageOS

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

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

~~~
amirmc
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).

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

~~~
amirmc
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](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.

------
zellyn
via
[https://lobste.rs/s/hgknhb/state_of_the_mirage_an_ocaml_unik...](https://lobste.rs/s/hgknhb/state_of_the_mirage_an_ocaml_unikernel)

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

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

~~~
mseri
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?

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

