Re: [MirageOS-devel] Charrua release

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

On 6 October 2015 at 11:05, Christiano F. Haesbaert
<haesbaert@xxxxxxxxxxxxx> wrote:
>>>> + Could you pull out Dhcp_structs into a separate ocamlfind library (i
>>>> tried tftp.wire for my Tftp lib) so that the structs can be reused (eg
>>>> in a packet parsing libpcap-alike)?  (One day this will happen for
>>>> tcpip as well so that you don't need to include "cstruct udp" et al.)
...
>
> So I gave a stab at this, but it seemed pointless without the cenum
> conversion, the only thing left would be a cstruct Dhcp.
> I had a look on your tftp library, and it seems all the parsing and
> such is in tftp.wire itself, while mine is in dhcp.ml, I only use a
> Dhcp_structs (which now I renamed to Dhcp_wire) so that the cstruct
> definitions play nice with merlin.
> Should we keep both ? I like the idea of a Dhcp module, and I think
> that is more important to be a separate library than the Dhcp_wire, or
> maybe both should be separated ?
> I'm starting the cenum conversion and that might shed some light on
> how to proceed.

FWIW my motivation was: there are cases where one wishes to parse (or
generate) structures without needing to implement server/client. The
initial motivation was a reimplementation of a tcpdump-like facility,
as used by (eg) ocaml-dns for its unit tests.

Hence, putting all code dealing with the wire-to-OCaml interface in
Tftp_wire, and then (I'm currently fiddling with this, slowly) all the
state machine logic in Tftp_S with the intent of having a Mirage
unikernel implementation that uses Tftp_S to create a server instance
(basically by bridging IO into Tftp_S).

(But I welcome better ideas how to structure all this!)

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

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