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

Re: [MirageOS-devel] hdhcpd working.

[+mirageos-devel -- Christiano's pioneer project on dhcp is working now!)

On 17 Aug 2015, at 10:14, Christiano F. Haesbaert <haesbaert@xxxxxxxxxxxxx> 
> On 17 August 2015 at 18:47, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> Just wondering -- before Mirage support directly, is it worth putting 
>> together
>> a mini-dnsmasq-style server so that we can play with it "in production"?
> I'm not sure, the problem is I'd to to release the Rawlink library I
> wrote: https://github.com/haesbaert/rawlink
> And frankly I don't like that code, I wrote too much stuff in C, so
> I'd rewrite that first.

As long as the OCaml interface is reasonably stable, it's probably ok
to release what's there.  At a quick read through, the C interface seems
ok -- it could be made safer by using C stub generation via ocaml-ctypes,
but the external OCaml mli would remain the same.

> Yesterday later hdhcpd got caught in a loop I guess, I didn't debug
> further, so there are some basic bugs still there.
> What is/was this mini-dnsmasq ?

I was just thinking that a lot of us use dnsmasq in our development
setups.  It provides a simple dhcpd+dyndns for local networks, and hdhcpd
could provide a similar interface.  It it uses Irmin as a key/value store,
the dnsmasq state could even be exposed via Git very easily as well.
That would get the parsing code tested out while the Mirage interface
gets written.

>> OpenBSD OCaml refresh seems to mostly work -- will get an ack from ports folk
>> and then apply the lot, so it should be easy to get your server added 
>> directly
>> from pkg_add when that's done.
> What is this ocaml refresh ? not familiar with it :D.

I took a swipe at refreshing all the OpenBSD OCaml ports so that we
have the latest versions of OPAM and associated libraries.

I'm aiming to get tlstunnel into ports, and activate ARM native code
mode again (hopefully just a bit of configure script hacking).

> I'm not sure how much work would be needed to convert to mirage, I'm
> not sure I want to maintain both mirage and a standalone-unix version
> in the future.
> Seems:
> 1 - Too much work
> 2 - An excuse for people not trying out mirage if they want to run hdhcpd.

Right, that's fair.  One good thing about the Mirage version is that
the Unix compilation mode can easily be enhanced to look just like a
native Unix daemon. A hdhcpd version that's portable enough to compile into
Xen mode can have a CLI parser and syslogger applied to the functor in
order to give a Unix tool that's very similar to one written for Unix.

> But now I'm unsure how much work is needed to convert to mirage, as I
> didn't do my first unikernel yet.
> I believe the bigger points are:
> * Convert the IO functions, I need to be able to write/read a full
> ethernet frame.

This should be just a matter of functorising over the ETHIF signature.
One difference from Rawlink is that it'll give you a Cstruct, and not
an OCaml string.  In general the use of Cstruct is recommended since
those are out-of-heap values and can directly wrap the IO buffers
from Unix or Xen.

> * Somehow receive the interface list.
> * Pass the configuration to the VM somehow, I think I read on the
> key/value module that converts the file into an ml file, that would be
> ok.

I need to look up the latest on this, but the OS.Env module should
do key/value maps via the unikernel command line.  Thomas/Magnus,
what did you end up deciding to use in Jitsu for unikernel arg parsing?


MirageOS-devel mailing list



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