[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

generalising oxenstored for unix nodes too



Raphael has been hacking away at the Mirage control stack, which
will keep *bidirectional* dependencies for most data structures.
That is, rather than a cache serving up a result, it will keep track
of who is using that result, and push it an update when the cache
entry changes.  This is very useful for the I/O subsystem, since
every flow can be notified when some value it depends on changes
(e.g. an ARP entry changing due to a live migration).

As part of this, we need a name service that will register and
coordinate different threads' I/O. It turns out that oxenstored
from xen-unstable is actually pretty nice: it is purely functional,
but coalesces transactions smartly.  It also has the massive advantage
that it already implements the Xenbus protocol, needed for Mirage
in microkernel mode.

What I'd like is to be able to use oxenstored for non-Xenstore
related things and run it on UNIX systems without the Xen* libraries
installed. I had a quick look at the source, and it seems fairly
easy...

- the Logger has some access logging towards the end that is
  Xenbus-specific, so moved that into a Xb_logger module
- Perms and Quota depend on Xenctrl.domid (which is just an int,
  not abstract) - Transaction coalesces based on whether or not the
  operations are Xenbus 'reads or writes'.

So it seems like we can functorize the transaction logic pretty
easily, into a Xenbus one and a more UNIXy one for other nodes.

Thomas, Dave, any thoughts on this? I was thinking of hanging a
first-class module from a node, which could be unpacked and decide
how to deal with that part of the namespace.  This way, we could
mix-and-match Xen portions of the namespace, as well as other nodes
that have completely different side-effects.

-anil



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.