Re: [MirageOS-devel] Charrua release

["Christiano F. Haesbaert" <haesbaert@xxxxxxxxxxxxx>]

On 10 October 2015 at 17:56, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> hey,
>
> On 10/10/2015 07:42, Christiano F. Haesbaert wrote:
>> We have released charrua-core \o/:
>> https://opam.ocaml.org/packages/charrua-core/charrua-core.0.1/
>
> great! :)

\o/

>
> I do have some questions, though:
> - is there a way to programmatically create a configuration, rather than
> providing a dhcpd.conf? would be great to be able to construct such a
> config in config.ml (or use magic to derive one from a given interface
> configuration) :)

Ack, that I can arrange, shouldn't be too much trouble.

>
> - what is the purpose of having config abstracted over an INTERFACE?

That is to abstract IO in/outside mirage, take a look at:

https://github.com/haesbaert/charrua-unix/blob/master/src/charruad.ml#L65

>
> I'm still not sure about the design: to separate the server logic from
> the side effecting computations and the store (which would allow testing
> more easily), I'd

I'm not super happy with the separation the way it is today either.

>  a) make a constructor for a server: val dhcp_ctx : config -> context
>  b) provide a `val handle : context -> Cstruct.t -> (context * Cstruct.t
> option * action list)` (which takes a (potential packet), and possibly
> produces a reply for that, and maybe a list of actions (log events,
> timers, ...)

I think doing this for the packet IO case could be straight forward,
since it's always input -> reply.

But lets say you build a list of actions and whatnot, now what if
another packet in the future comes which ends up making you cancel
that timeout, so you return an action "cancel timeout X".

Then the caller needs to know what timeout X is, and how to cancel it
and so far, isn't that a lot of work ?

I do agree with the principle and making the logic pure.

>  c) I'd abstract over the store by requiring three functions,
> `val get : Macaddr.t -> Ipaddr.V4.t option` and `val add : Macaddr.t ->
> Ipaddr.V4.t -> unit`, `val remove : Macaddr.t -> unit` in the server
> configuration (or sth similar, maybe using the Lease.t record?) -- thus
> users (tests!) can provide a Hashtbl, an Irmin backend, a Set, or just
> ignore them. (this is similar to how we implemented session resumption
> https://github.com/mirleft/ocaml-tls/pull/283)
>
> In my opinion, the core logic should be independent of lwt (similar to
> TLS and OTR).  The core should also be independent of a concrete
> interface (I might want to run this dhcp server on a vlan trunk as
> ip-helper, thus the environment should be responsible to add the
> ethernet header).. of course it needs certain configuration information,
> which I'd pass in directly.

I think I can start pulling out the IO and doing as you suggested, at
least for v0.2, that would alone remove the INTERFACE functors and the
rest of the IO packet separation.

So my suggestion is the following for 0.2:

1 - Make the server take an input packet as argument and return the
possible reply, thus removing IO from logic. Logs and Lease still stay
as they are.
2 - Work on persistent Lease as said before.
3 - Move the remaining Functors to something like Drup suggested.

Then I can experiment on making the rest of the logic functionally pure as well.

In the meanwhile I would like to put charrua-mirage in
mirage-skeletons/dhcp_server "as it is", so people have something to
test and whatnot. How about ?

>
> Since we have a dhcp server now, and also a dns server, it'd be nice to
> have an example unikernel which provides dhcp leases, and registers the
> client identifiers under some domain name (sth I hacked up several times
> years ago, using e.g. sauron http://sauron.jyu.fi/ or buddha
> https://github.com/dylan-lang/http/tree/master/examples/buddha).
>

Yeah that would be great, I think once we pull the dhcp packet IO of
the logic, that should be straightforward to do, then we can have a
mirage-skeletons/dhcp_named or something.

> I started to write up some lessons learned from developing protocol
> implementations, https://gist.github.com/hannesm/8f2e19738c60163d5357
> (feedback highly welcome, most likely I'm missing things).
>

Great, I read them but want to go over again with more calm.

>
> sorry for the long mail and thanks for contributing a dhcp server! :),
>
> hannes
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>

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