Re: Porting Mirage to FreeBSD

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Welcome to Cambridge, Gabor!  

Robert Watson, Balraj Singh, Gabor and I had an initial meeting yesterday
to chat about FreeBSD/Mirage integration.

The big problem any clean-slate effort such as Mirage faces is how to
evaluate it against existing solutions. So far, we've been doing rather
coarse analysis of a Xen microkernel appliance versus a virtual guest that
is running an equivalent userspace application such as BIND or lighttpd.

What Gabor is now going to look at is to port the Mirage platform library
to be compatible with the FreeBSD kernel interface, so that we can swap
(and eventually, run in parallel) the OCaml network stack alongside the
industrial-strength FreeBSD stack.

This will let us evaluate the application/kernel/hypervisor divide in a
significantly more fine-grained fashion.  For example, you could imagine
hosting the Mirage website directly as a kernel module running on native
FreeBSD, or writing a "socket server" to serve up POSIX system calls via
the Mirage network stack, and hence do interoperability testing using
existing, (mostly) well-understood userspace applications.

There are a few steps to getting this going:

1) Firstly, we want to simply get a cut-down OCaml runtime printing to the
serial console.  This should be fairly mechanical: the asmrun/ directory
in the distribution needs to compile against FreeBSD libkern.  The output
of an OCaml application can be obtained as an object file very easily:
$ echo 'let _ = Printf.printf "hello freebsd world\n"' > foo.ml
$ ocamlopt -output-obj -o foo.o foo.ml
$ nm foo.o

Most of the symbols are present in the runtime from asmrun/, and some are
debugger stubs and so forth. 

2) Second stage will be to add Io_page bindings. These are OCaml
byte-buffers that are reference counted and guaranteed to be page-aligned
(or rather, suitable for I/O transmission).  They should be a very close
match to the mbuf API, and permit zero-copy manipulation of pages within
the kernel.

3) Next, we need to figure out the best way to activate the event system
as a kernel module --- Mirage could run as a kernel thread, protected by a
lock against multiple CPUs, or be woken up via a dispatch thread. Either
one has different latency/throughput tradeoffs, and it'll be interesting
to investigate this on a variety of machines.

4) Finally, the syscall server will actually expose a user-space API from
Mirage.  This will probably be something of a stretch goal, but we should
be able to get basic, non-restartable system calls up and running. This
will also probably involve quite a bit of improvement of the TCP stack,
which Balraj and I can help with.

If anyone has any comments, feel free to pipe up on the list!

-anil

On Fri, Jul 06, 2012 at 12:11:47AM +0200, PALI Gabor Janos wrote:
> Hi there,
> 
> My name is Gabor Pali and I have just arrived to Cambridge to spend the
> upcoming months on bringing Mirage and FreeBSD a little bit closer to
> each other.  So you may expect some questions from me during this time
> :-)
> 
> I am an assistant lecturer at Eotvos Lorand University, Department of
> Programming Languages and Compilers, Faculty of Informatics of Budapest,
> Hungary, and I am about to complete my doctorate studies (hopefully this
> year).  I do research and teach functional programming, mainly Haskell,
> but I have some experience in F# as well -- my doctorate research is
> about developing operating systems in functional programming languages,
> which is quite a good match for Mirage, I think.
> 
> I have been also contributing to the FreeBSD Project for a long time,
> where I maintain the FreeBSD port of the Glasgow Haskell Compiler
> together with hundreds of Haskell Cabal packages, but I am interested in
> systems programming and have worked as a game engine programmer before.
> 
> I really appreciate the opportunity of joining you, and I am hoping to
> make Mirage work inside the FreeBSD kernel soon.
> 
> Cheers,
> Gabor
> 

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