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

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 18 Nov 2014, at 20:29, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:

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

would this need extending at all?  (if not, where does the knowledge that 
`connect ()` can be called on a module come from?)

would it also be possible to push the implementation types out to the libraries 
too? (`type network`, `val network`, `val tap0` etc)

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

...so mirage.mli would provide helper functions to generate this sort of code, 
but it would become the job of each library itself to support the code 
generation interface by calling those functions (ie., mirage.ml would no longer 
need to know about all mirage modules)?

that seems like a good thing to me...

-- 
Cheers,

R.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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