[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 :-)
Best, Thomas
|
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
