Re: generalising oxenstored for unix nodes too

[Raphael Proust <raphlalou@xxxxxxxxx>]

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


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


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


Cheers,
-- 
_______
Raphael