mirage xen shared memory rings

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

Hi,

I've recently been hacking on the mirage xen shared memory ring code. This code 
is the foundation for the virtual devices, in particular
* disks
* network interfaces
* console (critical for debugging)
* xenstore (critical for attaching other devices)

I've created a standalone library here:

https://github.com/djs55/shared-memory-ring

I've added a set of simple unit tests and fixed a bug where console output was 
being silently dropped (!) I think this explains the loss of debug messages 
that Balraj and I saw while investigating the TCP problem. The console and 
xenstore rings are now also lots faster since they use Bigarray.blit rather 
than a hand-coded copy-one-byte-at-a-time-while-loop.

My next steps are:
1. to make this library a dependency of the mirage-platform (rather than having 
the code inline)
2. to extract the xen disk and network interface support from mirage-platform 
and make these into separate libraries too
3. to define a shared-memory transport for logging / stats collecting

(2) should be interesting because the same xen disk and network interface 
support code should "just work" from userspace as well as kernelspace, if we 
add ocaml bindings for the xen "gntdev" library which allows userspace access 
to memory pages "granted" by a VM. It should be possible to:

a. "opam install gntdev blkback vhd" to install the relevant libraries and then
b. instantiate the blkback functor with the gntdev interface and the 
vhd-writing code to make a fully-functional xen virtual disk device from a 
toplevel... how cool would that be?! (Maybe it's just me...)

Cheers,
Dave