[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Charrua release

  • To: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Sat, 10 Oct 2015 16:24:32 +0200
  • Delivery-date: Sat, 10 Oct 2015 14:25:39 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=olfFGSC9oiiqJI3RSH11YnCTYhUR9CNDswl7nwBnSJ6M/Ar7HmQM7+3e1vU6xH53HVMY7hfKxXtg FF0oxkAK2BmGGO4FiEnw5L9jO83c1ZpRDBgYrHQ1wXE3PXUixCuZ
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

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).
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/:

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

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

-- 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 mailing list



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