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

[Jeremy Yallop <jeremy.yallop@xxxxxxxxxxxx>]

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.
>
> Jeremy (or anyone else familiar with MetaOCaml): is it possible
> to do an AST output from the results of staging, assuming that we
> don't do any cross-stage persistence?  That would let us hook it
> into the existing build chain quite easily.

It is, at least in principle.  You can write:

    let closed_code = Runcode.close_code .< fun x -> x + 1 >. in
       Print_code.format_code Format.std_formatter closed_code

to output source or

    Print_code.print_code_as_ast closed_code

to dump an AST, and it wouldn't be hard to add support for other formats.

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