Re: [MirageOS-devel] Charrua release

[Amir Chaudhry <amc79@xxxxxxxxx>]

> On 13 Oct 2015, at 11:09, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> 
> 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?)

Iâve just skimmed this and I think it would be a great addition to the docs on 
the website (along with an introductory post).  One thing that would be useful 
is pointing to (i.e. linking off to) real world examples in the libs we already 
have.  That would help people figure out which libs have good examples for the 
things being described (and provide some encouragement to explore the libs 
directly).

Christiano, it would be great to have a blog post to accompany whatever is 
added to mirage-skeleton.  Would you be able to do this? Iâm happy to 
proof-read and help out once thereâs an initial draft.

Thanks!
Amir












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