Re: [MirageOS-devel] OPW intern checking in!

[Mindy <mindy@xxxxxxxxxxxxxxxxxxx>]

Doubling as my update for this morning, here are some inline responses:
> > Mainly, as you say, this points to a lack of good regression tests and test 
> > infrastructure.  I have tried to make some unit tests but for TCP there are 
> > many balls that have to be kept in the air and I could not quite do it in an 
> > automated way.  The most successful of this kind of test was one in which a 
> > single VM would bring up 2 virtual interfaces and send specific patterns of 
> > data in both directions.  It knew what to expect and it could, if necessary, 
> > even examine the state machines of the two TCPs.  This was quite fragile - it 
> > would often stumble on something simple like bringing up two VIFs.
> The other option here is not to use Xen for testing the net stack at all, but 
> just use Linux with two tap interfaces.  That gives us the ability to use 
> tcpdump to inspect the traces as well...
>
> > On 2 Jun 2014, at 17:00, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:
> > My first thought is that I don't know how to get the workflow I've been using 
> > (start up a unikernel in Xen and throw a bunch of stuff at it from scapy) set 
> > up in Travis, but if that doesn't seem like obviously the wrong thing to do, I 
> > can look into it.  I would still like to look at Quickcheck as well.
> Similar to answer to Balraj above -- instead of spinning up a Xen VM, spin up a 
> user-level stack on Linux instead (using `NET=direct mirage configure --unix` 
> in the various skeleton examples).
>
> However, one downside to Travis is that it uses LXC (containers) for its 
> isolation, and so doesn't support tuntap.
>
> This does leave Balraj's suggestion as the best one: create two network stacks 
> in one Mirage program and get them talking to each other!
Playing around with this uncovered a logic problem in how DHCP setup 
works in the context of unikernels that don't want to run listeners; 
I've submitted an issue (mirage/mirage-tcpip #53) with more details.
> > Also, an update - Last week I wrote up another Treaty of Westphalia on finding 
> > a TCP bug and made Mirage implementations of chargen, discard, and echo for use 
> > in testing the TCP stack more directly. Today, I'm planning on getting a whole 
> > bunch of data from them and (I hope) finding some interesting results.
> The chargen/discard/echo sounds very useful indeed -- how about adding those 
> directly into mirage/mirage-tcpip in a lib_test/ (or examples/) directory?
I've just submitted a PR (#52) for this.

Thanks,
Mindy

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel