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

Re: [MirageOS-devel] Charrua release

  • To: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Hannes Mehnert <hannes@xxxxxxxxxxx>
  • Date: Sat, 10 Oct 2015 16:56:34 +0100
  • Delivery-date: Sat, 10 Oct 2015 15:57:14 +0000
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>
  • Openpgp: id=11B5464249B5BD858FFF6328BC896588DF7C28EE


On 10/10/2015 07:42, Christiano F. Haesbaert wrote:
> We have released charrua-core \o/:
> https://opam.ocaml.org/packages/charrua-core/charrua-core.0.1/

great! :)

I do have some questions, though:
- is there a way to programmatically create a configuration, rather than
providing a dhcpd.conf? would be great to be able to construct such a
config in config.ml (or use magic to derive one from a given interface
configuration) :)

- what is the purpose of having config abstracted over an INTERFACE?

I'm still not sure about the design: to separate the server logic from
the side effecting computations and the store (which would allow testing
more easily), I'd
 a) make a constructor for a server: val dhcp_ctx : config -> context
 b) provide a `val handle : context -> Cstruct.t -> (context * Cstruct.t
option * action list)` (which takes a (potential packet), and possibly
produces a reply for that, and maybe a list of actions (log events,
timers, ...)
 c) I'd abstract over the store by requiring three functions,
`val get : Macaddr.t -> Ipaddr.V4.t option` and `val add : Macaddr.t ->
Ipaddr.V4.t -> unit`, `val remove : Macaddr.t -> unit` in the server
configuration (or sth similar, maybe using the Lease.t record?) -- thus
users (tests!) can provide a Hashtbl, an Irmin backend, a Set, or just
ignore them. (this is similar to how we implemented session resumption

In my opinion, the core logic should be independent of lwt (similar to
TLS and OTR).  The core should also be independent of a concrete
interface (I might want to run this dhcp server on a vlan trunk as
ip-helper, thus the environment should be responsible to add the
ethernet header).. of course it needs certain configuration information,
which I'd pass in directly.

Since we have a dhcp server now, and also a dns server, it'd be nice to
have an example unikernel which provides dhcp leases, and registers the
client identifiers under some domain name (sth I hacked up several times
years ago, using e.g. sauron http://sauron.jyu.fi/ or buddha

I started to write up some lessons learned from developing protocol
implementations, https://gist.github.com/hannesm/8f2e19738c60163d5357
(feedback highly welcome, most likely I'm missing things).

sorry for the long mail and thanks for contributing a dhcp server! :),


Attachment: signature.asc
Description: OpenPGP digital signature

MirageOS-devel mailing list



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