Re: Current state of the UNIX backend

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 25 May 2013, at 20:03, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:

> On 25/05/2013 14:16, Anil Madhavapeddy wrote:
>> On 24 May 2013, at 19:23, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:
>> 
>>> Hi all,
>>> 
>>> Apparently, the current state of mirage for UNIX-direct is broken for me.
>>> 
>>> Could you test it for me, Mac users:
>>> 
>>> cd mirage-skeleton/basic
>>> mirari configure --unix
>>> mirari build --unix
>>> sudo ./mir-hello
>>> 
> 
> 
> So, thanks to Anil we now have a fixed version of tuntap for Mac (for some 
> reason, the code was already working on Linux).

It's because the Val_int fix was only in the __APPLE__ ifdef, so your other 
Linux code was just fine.

> The next problem I have is with the new backend on Mac (please test for those 
> who can):
> 
> * Use my repo (git://github.com/vbmithr/, mirage-platform, mirage-net and 
> mirari pinned to branch new-unix-backend2). Pin those packages and install 
> them.
> 
> * go to mirage-skeleton/basic
> * mirari configure --unix
> * Edit the generated file backend.ml to add a Tuntap.set_ipv4… line in order 
> to assign an IPv4 on the host side for the unikernel (mandatory on mac).
> * mirari run --unix

So a much easier way to debug this sort of issue is to build a unit test that 
expresses the desired behaviour first.  I put a small packet dumper for tuntap 
in:

https://github.com/avsm/ocaml-tuntap/blob/master/test/nonblock_read.ml

You can build this without any other dependencies by:

$ make
$ ocamlbuild _build/test/nonblock_read.native
$ sudo ./_build/test/nonblock_read.native

and if you ping the new interface, you should see hexdump packets on the 
console.  I do see these on both MacOS X and Linux successfully.  If Mort does 
too, I'll be convinced it actually works :-)

And now the question is why the Mirage libraries are different.  I'm guessing 
it's to do with setting the non-blocking flag, which is done via a stub at the 
moment.  If you make the behaviour of Ethif match that of my test case, then it 
should spot the problem.

PS: I also noticed that the netmask on the tap0 when you ifconfig is 
"0xff000000", which isn't the same as the "0xffffff00" I was trying to set it 
to.  It didn't matter for this test, but should be fixed too or else risk 
network routing heisenbugs...

-anil