|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Charrua release
On 10 October 2015 at 16:24, Drup <drupyog+caml@xxxxxxxx> wrote: > If you need to define this Make functor inside unikernel.ml for the simplest > example you have, it should be in your library directly. Regardless of other > needs (integration with the other mirage libraries): > > 1. Make *one* functor that takes simple arguments (apparently, CLOCK, IP and > NETWORK, in your case, I think). I was thinking on doing something simiilar and also move the INTERFACE implementation inside the implementation, but then I'd be just hiding code I guess. When you say simple arguments you mean simple values ? as in, not a functor. > 2. Wait for https://github.com/mirage/mirage/pull/441 to be merged > 3. Add a combinator. > 4. Profit ;) > > > Le 10/10/2015 08:42, Christiano F. Haesbaert a Ãcrit : >> >> We have released charrua-core \o/: >> https://opam.ocaml.org/packages/charrua-core/charrua-core.0.1/ >> >> Many thanks to Richard, Anil, Hannes, David and all the people who >> helped me through it. >> >> So now it should be possible to run your dhcp server in mirage by >> cloning: https://github.com/haesbaert/charrua-mirage >> This repository was made to be integrated into >> mirage-skeleton/dhcp_server, but looking at it now, it's to >> unhygienic, most of the code in mirage-skeleton has just a few lines >> of hooks and so on, while charrua-mirage has too much logic in it. >> >> Should we integrate charrua-mirage into mirage-skeleton as it is ? >> >> My proposal so far is "yes", in the meantime I'll create a transition >> library between mirage and charrua-core, so that the unikernel.ml can >> be super stupid for the simple case, much like what it's done in >> mirage-skeleton/conduit_server. >> >> Thoughts ? >> >> On 7 October 2015 at 14:56, Christiano F. Haesbaert >> <haesbaert@xxxxxxxxxxxxx> wrote: >>> >>> 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 > > > > > _______________________________________________ > 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 |