Re: [MirageOS-devel] test, quality, tcpip

[Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>]

On 6 May 2015 at 10:40, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:
>   - improve and formalize (create?) error communication for bad state
> transitions, syntactically OK but semantically bogus packets, etc

The only useful error communication I can think of is counters of
types of error, which you can use when deliberately testing protocol
errors or for debugging. Networking is unusual as there is no real use
case for error handling, it is just going to be a denial of service
attack if you dont discard the packet asap.

>   - possibly it makes sense to break this package up entirely into separate
> protocol implementations and rely on the `mirage` frontend tool (or user
> request, outside of the Mirage ecosystem) to manage dependencies between
> them - see below
>
> Most of the above is focused on splitting up the code in `tcpip`; there are
> probably other ways to do it, and likely some of them make more sense than
> what I'm proposing.  It seems to me that there are (at least) two reasonable
> ways to split up some of the code in `tcpip`:
> * horizontally layerwise, i.e. all code to do with ARP is in one package
> (serializing/deserializing, state machine/side effects), same for ipv4,
> ipv6, etc
> * vertically concernwise, i.e. all serializing/deserializing code is in the
> same place, all action-taking code (probably with some more sensible
> subdivision) is in the same place, etc
> * some other way I haven't thought of that makes way more sense (your
> proposal here!)
>
> A horizontal division is the only thing that really potentially gives any
> benefit for users that I can see - linking in only the layers we need makes
> for smaller binaries (at least until we have dead code elimination).  It
> also seems to have less potential for external API breakage causing other
> repositories to become unbuildable (thinking of the case where e.g. I want
> to support a new DHCP option, which might require me to both expose a new
> variant type for DHCP.Option.t and write some handling code in what's
> currently dhcpv4_client.ml); in a regime where the serializing/deserializing
> code and the actual implementations which receive and send data are in
> separate packages, they need separate, coordinated releases.  As a bonus, we
> already have module types in `mirage-types` for defining reasonable
> interfaces between these layers.

Horizontal seems the most useful, being able to make smaller images
that just support ipv6 (no ipv4, no arp) for example is useful, or
that only understand the lower layers for network layer applications
such as filters and switches.

Justin

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