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

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> 
> 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:

https://github.com/mirage/mirage/blob/master/lib/mirage.mli#L461

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":

https://github.com/mirage/mirage/blob/master/lib/mirage.mli#L498

> 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.

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