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

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

On 27 March 2015 at 17:28, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 25 Mar 2015, at 15:57, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>> 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



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