Re: [MirageOS-devel] Charrua release

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

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?

Not a problem per se, but functors make it harder later to "just use"
the module, so I'm trying to avoid it.

I've functorized over V1.CLOCK now, but instead of functorizing Lease
with V1.CLOCK as well, I now pass the current time as an argument.
This has the advantage of not having any time delta between two calls
if we pass the same current time, it also makes it easier to test or
write regression tests, commit is here:

https://github.com/haesbaert/charrua-core/commit/d542696510a861064b2db04e062e77bd76236284

With this, clock.mli is gone.

I'm working on the other points now :D.

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