|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Charrua release
On 13 October 2015 at 13:18, Amir Chaudhry <amc79@xxxxxxxxx> wrote: > >> 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. > Awesome ! Sure thing, I'll try to have something by Saturday, sorry for the delay in answering. So the blog post would contain some introduction and a how-to ? Could you point me to some blog entry which is analogue to what this would be ? Just so that I have a clearer idea. Christiano > Thanks! > Amir > > > > > > > > > > > > > _______________________________________________ > 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |