[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

hey,

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
https://github.com/mirleft/ocaml-tls/pull/283)

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
https://github.com/dylan-lang/http/tree/master/examples/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! :),

hannes

Attachment: signature.asc
Description: OpenPGP digital signature

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

 


Rackspace

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