Re: [MirageOS-devel] Charrua release

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

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