Re: [MirageOS-devel] Charrua release

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

[ 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 :)

>> + 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.)

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel