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 _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
