[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |