Re: mirari updates

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 16 Mar 2013, at 12:21, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:

> On 28/02/2013 18:13, Anil Madhavapeddy wrote:
>> I had a quick chat with Haris about this.  I think what we're missing in the 
>> UNIX backend is a simple control socket that mirrors the operations that 
>> Xenstore provides a VM: start, stop, suspend, hotplug device, and so on.  
>> Without this, we're forced to hardcode many control operations in the 
>> library directly.
>> 
>> If we make the runloop of a UNIX Mirage process mimic the Xen version, then 
>> many of these hacks go away.  For instance, the bridging configuration can 
>> be done from a command line utility that sets up tun (or pcap) devices, and 
>> then passes the fd to the listening Mirage UNIX process.
>> 
>> It's very Erlang and actor-like, but quite easy to build into Mirari with a 
>> bit of cmdliner magic.  Dave already has an Lwt fd-passing library I believe.
>> 
>> -anil
> 
> Hi.
> 
> This afternoon I decided to work again on Mirari and I’ve been thinking about 
> things. First, this message. I did not understand it much at first reading 
> but it makes more and more sense.
> 
> If I understand well, the best option is to make mirari emulate xenstore when 
> using the unix backend. This way, we can get rid of all the "hacks" for the 
> UNIX backend, the mirage kernel will just use the same interfaces "as it was 
> running on Xen" and mirari will emulate the environment (basically a xenstore 
> daemon if I understand well). I’m going to work towards that.

Dave had some patches to remove the Xen dependency from xenstored and let it 
run on a normal UNIX box.

However, I wonder if a better approach might be to explicitly encode the 
various operations, and map those to Xen. The reasoning here is that the 
Xenstore interfaces are a bit ad-hoc, and so a fresh approach would avoid 
propagating various bugs to future backends.

Remember that there is more to this interface than just Xen+UNIX: we also 
(eventually) want to integrate a Javascript, kFreeBSD and Raspberry Pi backend: 
each of these will have their own unique ways of expressing device hotplug.

Why not just start off the UNIX one with a very simple 'process lifecycle' -- 
start, stop, suspend, resume that is similar to Xen, and then a device 
registration mechanism for network+block.  This should map to Xen fairly 
easily, but not introduce a dependency on Xenstore.

-anil