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

Re: [MirageOS-devel] mirage configure & dynlink (was: V1 vs V2 mirage-types)

> the question that occurs to me is: is there enough commonality in the code 
> currently being generated that some kind of standard protocol can be defined? 
>  (i guess this is the set of combinators?)  after a quick glance through a 
> sample main.ml it seems this might be possible, though i might easily be 
> missing something. the kind of generated code in there appears to be of four 
> forms:

Every mirage implementation needs to the following signature to become a 
combinator in the mirage eDSL:


The define the opam package it is from, the ocamlfind libraries needed, the 
configuration and clean actions (and a function to make relative paths absolute 
in the configuration values).

This signature is a bit opaque, especially for the "configure" part, which 
could, as a side-effect, add some text to "main.ml" using "append_main":


> let vn () = Vn.connect "n"
> module M = Server.Main(V1)(V2)...(Vn)
> module D = Dd.Make(Dm1)...(Dmn)
> let d () = 
>       v1 () >>= function `Error e -> fail (Failure "v1") | `Ok v1 -> 
>       v2 () >>= function ... ->
>       ... ->
>       return (`Ok (v1, v2, ..., vn))

Indeed, most of the devices adds some text to "main.ml" which looks like that 
part. So I guess, we could export some helper functions for this kind of 
generated code.

MirageOS-devel mailing list



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