Re: [MirageOS-devel] Charrua release

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

On 13 October 2015 at 12: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?

Oh, that's because Config needs the interface ip addresses to build
subnet records, it's not just the file parsed, that can be decoupled
as well in the future.

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

I'm happy to try it out :P

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

Ack.

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

Great, this week has been a bit weird, so I'm slow to answer and still
didn't go over the text again.

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