[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 11 Jun 2014, at 18:58, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:

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

I've released TCPIP 1.1.5 with this DHCP logic fix, the FIN leak, and the 
examples all merged!

https://github.com/ocaml/opam-repository/pull/2301

-anil


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.