Re: [MirageOS-devel] Serving each URL from a separate unikernel: an experiment

[Jeremy Yallop <jeremy.yallop@xxxxxxxxxxxx>]

On 27 March 2015 at 17:53, Jeremy Yallop <jeremy.yallop@xxxxxxxxxxxx> wrote:
> On 27 March 2015 at 17:28, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 25 Mar 2015, at 15:57, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA384
>>>
>>> On 03/25/2015 15:43, Mindy wrote:
>>>> Also, none of the unikernels expect to serve anything but their
>>>> front pages, so one could probably remove the path-matching logic
>>>> from dispatch.ml, and just always serve the (only) contents of the
>>>> KV_RO fs. :)
>>>
>>> yep... that's what the btc piÃata does (here:
>>> https://github.com/mirleft/btc-pinata/blob/master/unikernel.ml#L109,
>>> where page is cow
>>> https://github.com/mirleft/btc-pinata/blob/master/page.ml). no
>>> dispatch involved, it doesn't even wait for the GET request.. :)
>>
>> My MetaOCaml bleeper just went off!  It should be possible to stage
>> the dispatch function and emit a dispatch-free version by
>> partially evaluating it with the URL.

Is this the dispatch function in question?

   
https://github.com/MagnusS/vm-per-url-experiment/blob/d64f7eb38488/mirage/dispatch.ml#L32-L42

That certainly looks very stageable, but I think you'd have to
eliminate the lwt syntax, since MetaOCaml and Camlp4 don't currently
play happily together.

Of course, once you start staging away overhead it's tempting to keep
going, so you might end up transforming everything down to a single
call to write a string literal.

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