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

Re: generalising oxenstored for unix nodes too

On Tue, Feb 14, 2012 at 11:00 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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).

Using FRP for configuration is quite nice. In a nutshell, FRP (Functional
Reactive Programming) is a declarative way of handling variations. In FRP,
values are time-varying (not always the same) but still bound in a declarative
way (the relation by which they are defined is always the same).

E.g. when defining a value (z) as the sum of two other values (x and y), the
value carried by z will change whenever the values of either x or y does.

Hence, FRP guarantees consistency (which is nice for configuration) and allow
one to monitor for changes.

> 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.

The idea is to have each successful transaction in the key-value store trigger
an FRP update cycle (so that all the values that depend on some configuration is

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

We could export the variables using the 9P protocol (thus giving remote
configuration access, the ability to use it as a procfs and a cool researchy

> 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.

Why not use a functor. I'm not sure there is a case for dynamically switching
between the Unixy and the Xeny versions and thus the need for a first-class
module. Or better yet, use mirage as the application synthesis and specialise
the module at compile time.




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