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

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

Thanks for your email Mindy!

We should also 1) figure out which of the error exposing/handling proposals won and 2) start using whichever one it is.

I had a first experimentation[1] with the new error handling based on Rresult[2]. The branch needs to be rebased and need more feedback, but I think that's the direction in which we should go.

An other point which is cruelly missing is a proper logging system - which is central when debugging runtime errors.

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.

I think both splits make sense:

- you want an horizontal split for opam packages, as you want to be able to select which part of the network layer you want to assemble in your final application, and do not worry about installing the rest of the stack

- you want a vertical split in each packages (separate libraries for instance) to separate the IO code (serialization/deserialization) from the "pure" state-machine logic. The TLS code is a good example of that.

To go in that direction, I really would like to split the channel library from tcpip, so I'll probably do that today :-)


MirageOS-devel mailing list



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