Re: mirari updates

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 5 Mar 2013, at 22:14, Vincent B. <vb@xxxxxxxxx> wrote:
> 
> Ok. I’ve read about the CAP_NET_ADMIN but thought at first that it was not a 
> very practical possiblity. It would work well with Mirari on Linux, Mirari 
> would have to have that cap and it could create tun/tap interfaces. For other 
> OS, it seems that sudo is needed. But this looks really feasible indeed. And 
> an ocaml-tuntap library is probably the best way to implement those 
> functions, as they will probably be needed by other ocaml programs in the 
> future. As everybody seems to agree on that I’ll do my best to write such 
> small library, if we were going to port mirage-platform code into Mirari, it 
> should not be much more work to put it into such library instead.

Agreed.  The goal for Mirage-platform is to strip it down into a set of 
smaller, reusable libraries.  Dave has already removed xenstore from there, for 
example, and the Blk/Net device drivers are also now in their own repositories.

Doing the same with the UNIX backends makes it much easier to re-use the code 
in other contexts, such as Haris' NS3 work, and makes testing and portability 
easier.

> The other possibility is to _not_ bother to setup tun/tap with mirari, but 
> let the use issue the right commands instead (ip tuntap ... or whatever 
> command on other unixes). This is probably a bit less convenient for the 
> user, but it removes some complexity from mirage/mirari, and it makes the 
> user more aware of what is under the hood. My opinion on that is that 
> automatic setup is better ONLY if it works perfectly for everybody. If 
> implementing it properly for all platforms is too tricky such that it does 
> not work equally well for everyone and frustrates users, then it is seems 
> better to me to explain users that they have to setup a tuntap interface, and 
> how to do it.

I agree with this too.  I only possible issue in on MacOS X, where there is no 
tunctl command, and so something has to:

- open() /dev/tap0
- configure it with ifconfig
- pass the fd to the application to read()/write()
- close() it which destroys the interface.

This is an unfortunate API, as it mandates fd passing as far as I can tell.  
Unfortunately, most of the users of unix-direct in Mirage will be on a Mac!

>> 
>> A (very) simple first start would be to just generate the minimal .conf file 
>> (as mir-run does at the moment) and directly call 'xl/xm create -c'.
> 
> Finally I think this is a better first solution (and maybe a better last 
> solution as well). Because it does not require the dependency to libvirt, and 
> that will always work. I’ll definitely implement that first, and I’ll have a 
> look at libvirt later if needed.

Agreed.

> 
> So, basically, here is what I’m going to do for mirari run, in order (if 
> everyones agree):
> 
> 1. mirari run for UNIX backend: Basically figure out / fix the tuntap 
> business, and just run the executable.
> 
> 2. mirari run for Xen: Create a xl config file, then run the kernel (using xl 
> exe/ (or libxl if available ?)
> 
> 3. mirari run for EC2: Implement the automation of sending kernels on EC2.

Agreed!  There's a script to wrap the kernel here:
https://github.com/avsm/mirage/blob/master/scripts/ec2.sh
...but give me a shout if you need a hand with it.

> 
> As for making mirari do the opam switch itself (and thus specify the desired 
> backend in mirari config file), I have no opinion about it. To me personally 
> I don’t perceive that as very important (I don’t mind opam switching 
> manually, because I don’t think it is required to do it often). But I can 
> certainly implement it if needed (as you explained in former emails).

I think this would be very useful to put in, since it would let us remove the 
Unix module entirely from the Xen OPAM switch.  It's currently in there since 
some of the host tools are compiled in that switch (i.e. UNIX binaries), and it 
leads to confusing error messages.

A clean separation of host tools (in a normal OPAM switch, where Mirari is 
compiled for example) and the weirder backends such as Xen make future backends 
easier too.

-anil