|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Charrua release
On 6 October 2015 at 12:05, Christiano F. Haesbaert <haesbaert@xxxxxxxxxxxxx> wrote: > On 30 September 2015 at 18:50, Richard Mortier > <richard.mortier@xxxxxxxxxxxx> wrote: >> [ Adding the list as discussion may be of more general interest. This >> concerns Christiano's DHCP server, Charrua, at >> https://github.com/haesbaert/charrua-core, >> https://github.com/haesbaert/charrua-mirage and >> https://github.com/haesbaert/charrua-unix. ] >> >> On 30 September 2015 at 13:39, Christiano F. Haesbaert >> <haesbaert@xxxxxxxxxxxxx> wrote: >>> >>> On Wednesday, 30 September 2015, Richard Mortier >>> <richard.mortier@xxxxxxxxxxxx> wrote: >>>> >> ... >>>> Some random thoughts: >>>> >>>> + Is there a reason why you include clock.mli rather than depending on >>>> mirage-types and using the definition from there? >>> >>> Probably inexperience, that was for charrua-unix to be able to use the Ocaml >>> Clock module without having a functor, but I want to change that, didnt find >>> a better way at the time. >> >> Given you're using functors elsewhere, why is it a problem to use a >> functor for Clock too? >> >>>> + I notice the INTERFACE type you define -- is this something that we >>>> should think about adding to mirage-types? >>> >>> Don't think so. >>> This is an artifact of having the library working outside mirage >>> (charrua-unix), i basically need to tell the Server module how to do IO and >>> what is an interface. Im not too happy with the way I wrote this, perphaps >>> there is a better way ? >> >> This may bear some thinking about-- I wonder if the right thing to do >> is to just use the Mirage types, functors, libraries, etc, but (using >> @drup's shiny new Functoria-based Mirage DSL implementation) implement >> a "native Unix" backend so that cmdliner and other things can be used >> as-is. That way you can leverage the module types and libraries all >> the way down, but aren't tied to having the entry point look like a >> unikernel (hence can pass params etc as you would normally). >> >> All-- thoughts? >> >>>> + Could you pull out Dhcp_structs into a separate ocamlfind library (i >>>> tried tftp.wire for my Tftp lib) so that the structs can be reused (eg >>>> in a packet parsing libpcap-alike)? (One day this will happen for >>>> tcpip as well so that you don't need to include "cstruct udp" et al.) >>>> I can try and put a PR together for this if you prefer... >>> >>> Sure let's do it, but by PR you mean ? >> >> Pull Request :) >> > > So I gave a stab at this, but it seemed pointless without the cenum > conversion, the only thing left would be a cstruct Dhcp. > I had a look on your tftp library, and it seems all the parsing and > such is in tftp.wire itself, while mine is in dhcp.ml, I only use a > Dhcp_structs (which now I renamed to Dhcp_wire) so that the cstruct > definitions play nice with merlin. > Should we keep both ? I like the idea of a Dhcp module, and I think > that is more important to be a separate library than the Dhcp_wire, or > maybe both should be separated ? > I'm starting the cenum conversion and that might shed some light on > how to proceed. > So I think I have addressed all the points now. * Fixed the clock.mli inclusion. * Converted relevant types to cstruct. * Split into charrua-core.server and charrua-core.wire as suggested. Then on the next release I can concentrate on Alistair irmin lease storage and some regression tests. I still have to write and document a dhcp_wire.mli. If you could have a look just to make sure I got it right, would be awesome :D. >>>> + Curiosity: Was there a reason to not use the Cstruct `cenum` >>>> construct for declaring the codepoints etc? (Wondering whether >>>> something that replaces `cstruct ... { }` could/should be replaced >>>> with something that enables`with cstruct` a la `with sexp`.) >>> >>> i didn't know about cenum, that will make things easier, I will work on that >>> thus week. >> >> Cool. In general I think we have an inclination now to remove camlp4 >> syntax extensions where possible -- I don't know if anyone has looked >> at replacing cstruct.syntax though (which I would guess is the most >> commonly used now we don't generally use lwt.syntax). Anyone? >> >>>> + Dhcp_logger -- Anil, what's the status of dog at the moment? Is >>>> there a logging framework ready for use/Is dog the place to start for >>>> one? (I'll push Tftp over onto it as well if so.) >>> >>> That was also to be able to use charrua-core outside of mirage. >> >> I understood that Dog depended on Irmin rather than Mirage, but I >> might be wrong. (@samoht?) >> >>>> + Alistair had started adding (possibly got to some kind of >>>> completion) Irmin support for the state in his version (based directly >>>> off mirage-tcpip -- >>>> >>>> https://github.com/alistairfisher/irmin-dhcp/commit/fb56e771613333d08397033b8c4f830a519db5a0) >>>> -- would be great to look at adding/merging this somehow. >>> >>> I agree, i can work on merging his code, I would do it for 0.2 though. >> >> Fair enough :) >> >>> Bear in mind my ocaml-foo may not be on paar, you should see other naive >>> mistakes and/or uncommon idioms. >> >> I'm sure those with sufficient experience will eventually point them out :) >> >>> If supporting Charrua-core outside of mirage contaminates too much of the >>> design, I can drop charrua-unix. This was in fact my first idea, but then I >>> figure it would be interesting on the architectural level, since it provides >>> a stronger separation between the core logic and the rest. >> >> FWIW, what I was trying to do with `ocaml-tftp` was to have the >> library and then Mirage and (pure) Unix servers (and ultimately, >> clients) in a single repo, under different directories, using Oasis to >> generate the necessary build runes and OPAM to manage installation of >> different generated ocamlfind components. (Though I just noticed I >> need to split that down more.) Not entirely successful (or finished!) >> so far, but it mostly seemed to work. (And meant I didn't have to >> worry about too many repos.) >> >> -- _______________________________________________ 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 |