[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



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