[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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.