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

[MirageOS-devel] Dispatching boilerplate and the tutorial

  • To: "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Thu, 16 Jul 2015 20:25:21 +0200
  • Delivery-date: Thu, 16 Jul 2015 18:26:08 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=to:from:subject:message-id:date:user-agent:mime-version:content-type; b=VNOUuZNnXAdaWqc9CgRKg6mmeuONjcWJ1TbtEFShVX0UPHF9mjjj5dypZT4gjtOtvWUj0dl/fKPf jO29EIPcbUxSFkHas6fKnnctIa4qWDpTYIPTRpVOfQG6Jj/5cOB5
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

The mirage guide presents nice and simple unikernels in the first tutorial[1], which is a very gentle introduction to mirage things, and then suddenly drop you into this: https://github.com/mirage/mirage-www/tree/master/src

The intention seems to be to present the config.ml and makes you try various configurations, but I don't think it works that well: people are going to try to understand dispatch(_tls).ml, because that's where most of the meat is, and these files are a bit messy, to say the least.

The next tutorials are not really related to mirage (CI, opam, profiling), so it is pretty much the end note of the mirage guide.

I see various issues:
1) mirage-www is not minimalistic. Now that mirage-seal is here (and in particular the static files[2]), maybe that should be used instead 2) Defining a unikernel that serves stuff to the web is a good amount of boilerplate. Also, considering the amount of indirections, this boilerplate is not obvious for a beginner. The main file is basically 100 lines of plumbing to be able to call the dispatch function. This boilerplate is now embedded into mirage-seal which is very good, but I think it should be put into a small reusable library. To add insult to injury, some of this plumbing is responsible for setting up the tls chain, and we all know this code should really not be done by the end user (regardless of how easy it is, by comparison). 3) The tutorial doesn't really explain the relation between various libraries that you end up using, in particular how the various cohttp things fit into the grand scheme.

I wonder how feasible it is to define various new modules/combinators that are usable in the config files, such as a fully setup HTTP(S) *server* stack, or a crunch device (without the need to redefine read_fs[3] everywhere ...). The main issue I see is that it adds even more things in mirage/mirage-types....

[1]: https://mirage.io/wiki/hello-world
[2]: https://github.com/mirage/mirage-seal/tree/master/static
[3]: https://github.com/mirage/mirage-www/blob/master/src/dispatch.ml#L71-L77

MirageOS-devel mailing list



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