Re: [rust-dev] Rust on Xen

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Fri, Mar 01, 2013 at 01:46:58PM -0800, Brian Anderson wrote:
> On 03/01/2013 08:37 AM, Tim Ford wrote:
> >The OCaml-on-Xen OpenMirage (http://openmirage.org/) project is
> >very interesting to me.  The idea is that your OCaml application
> >is compiled directly into a bootable Xen microkernel image.
> >Rather than running inside an OS, your OCaml links to a "libOS", a
> >library that provides all the OS services in terms of Xen
> >hypercalls.
> >
> >What are your thoughts regarding whether the same could be
> >accomplished with Rust?  You'd have to reimplement the Rust
> >runtime and many OS services, though perhaps the work done for
> >OpenMirage could be of some help there.
> >
> >It seems like Rust would be a great language for this.
> 
> I am interested in this. What they are doing does sound a lot like
> Rust and I would like us to get to the point where we can write
> kernel code in Rust. As Graydon mentioned though, our runtime code
> isn't structured to allow this yet, but we are inching closer. We
> probably shouldn't try to do it until after the scheduler rewrite
> because `core` depends on a bunch of runtime code that doesn't have
> a future and isn't worth porting to kernelspace. Afterword though, I
> expect the relationship between `core` and the scheduler to be
> [reversed], so that all the runtime machinery will be optional. At
> that point it should take just a very small platform abstraction
> layer to implement `core`, and we can think about the multithreading
> separately.
> 
> [reversed]: https://github.com/mozilla/rust/issues/5157
> 
> I talked briefly with Anil (from openmirage) about this subject last
> year, but it would be nice to touch base again sometime. I've copied
> him on this thread.

We've been doing a bunch of work to make it easier to share unikernel code
between different languages.  Most of this is in the Xen control stack,
where having a low-latency VM interface makes it easier to spawn virtual
machines on-demand (instead of the seconds it currently takes in many
cases).

As for the actual runtimes, we've taken an extreme position in Mirage to
strip away much of the C code:

- cooperative threading in OCaml, with everything boiling down to a single
  Xen domain poll.  No preemptive threading at all means that the runtime
  is extremely simple, but the only way to get parallelism is via multiple
  virtual machines.

- support for 1 vCPU only.  For many services such as HTTP, it's easier
  to spawn multiple single-vCPU VMs than it is to deal with multi-vCPU
  scheduling.

- compile-time specialisation to let configuration directives be compiled
  directly into the application.  Most of the Mirage libraries are 
  'policy-free', and the application glues it all together.  This giives
  us a lot of flexibility when building applications, but makes the
  build system much more complicated.  We're building a system called
  'Mirari' which hides much of the build-time complexity via a config
  DSL, though: http://github.com/mirage/mirari

- C bindings are mostly banned, which means that we've had to reimplement
  most protocols in pure OCaml (including device drivers).  The huge
  upside to this is that we can get rid of almost all of the usual
  embedded libC.  We only require a malloc and printf implementation
  at the moment, and should be able to get rid of the latter quite soon
  with a smarter Printf library.

All of these restrictions can be relaxed, at the expense of greater
complexity in the runtime.  I imagine that's where a lot of the
interoperability will come in: start with a non-preemptive boot library,
add on threading support, and then bits of libC.

It should be quite easy to build a multi-language unikernel that calls
back from the OCaml boot+TCP stack into the Rust runtime. See this GSoC
proposal:
http://wiki.xen.org/wiki/GSoC_2013#Towards_a_multi-language_unikernel_substrate_for_Xen

Also Xenopsd, which is the simple toolstack that Dave Scott is working on
at Citrix: http://wiki.xen.org/wiki/Xenopsd

You can also read more information about Mirage in the upcoming ASPLOS
2013 paper: http://anil.recoil.org/papers/2013-asplos-mirage.pdf

cheers,

-- 
Anil Madhavapeddy                                 http://anil.recoil.org