Re: [MirageOS-devel] Charrua release

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

On 10/13/2015 08:35, Christiano F. Haesbaert wrote:
> On 10 October 2015 at 17:56, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>> 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.

Cool!

>> - 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

But why should Config use any IO?  Shouldn't it receive a string and
return a Config?

>>  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 ?

While it might sound like 'a lot of work', it actually is being explicit
about which side effects should happen.  And describing them in an
explicit style (using a sum type) makes the code easier to understand.

I don't have experience which applying this style to protocols with
timers, it might turn out to be too troublesome; but I think we should
try it out :)

Certainly, someone who just wants to setup a DHCP server shouldn't be
pestered with these details, this is why a thin convenience layers
(using Lwt, Unix, Mirage, ...) are useful.

> 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.

\o/

> 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.

A decent first step!

> 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.

Cool!

> 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 ?

I think this is a great idea (would really like to have a configuration
option which derives from the already statically configured IPv4 stack).

> 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.

\o/

>> 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.

I'm happy to get feedback (and might turn this into something more
tutorial-style, maybe with more concrete examples?)


hannes

Attachment: signature.asc
Description: OpenPGP digital signature

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