Re: [MirageOS-devel] v1/v2/vN-- a discussion

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 28 Nov 2014, at 16:40, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:
> 
> all;
> 
> just had a chat with thomas regarding the V1/V2 discussions from last week. 
> this is my attempt to capture the results, which i fully expect thomas to 
> have to correct :)  
> 
> the problem is essentially that we have several implicit dependencies that 
> have to be captured between a library author and the mirage tool author: 
> which opam packages contain libraries that implement which `mirage-types` 
> signatures and also provide `'a impl` values satisfying `'a typ` types in the 
> mirage tool.
> 
> thus when a library author wants to rev a library (eg., dave wants to change 
> V1.FS_LWT, or we want to support the equivalent of a `mirage-dev` branch) 
> there are several things that may need updating: `mirage-types` has to have 
> the signature updated, the implementations of that signature need to have 
> their code updated, any dependencies between those implementations and other 
> opam packages/ocamlfind packages need to be captured in the mirage tool (eg., 
> Makefile generation to install correct packages and libraries), and the 
> mirage tool needs to potentially have code generation for that implementation 
> updated as well. this is all rather messy.
> 
> thomas managed to explain things to me sufficiently that i realise this is 
> just gnarly and intertwined and that's the way it is :)  but there were two 
> relatively easy steps that seemed to make sense and would help us manage this 
> a bit better in the relatively near-term:
> 
> 1/ refactor the mirage tool so that the dependencies between all `'a typ` and 
> the opam packages and findlib packages that implement them are explicitly 
> pulled into a single datastructure.
> 
> 2/ refactor the mirage tool and current mirage library implementations so 
> that the functions implementing the code generation that the mirage tool does 
> (to create the `main.ml` when it compiles a `config.ml`) are moved out of the 
> tool and into the implementations themselves.

I think this one sounds useful, but has the potential to just be shuffling the 
problem around instead.  We would move the code generation logic into the 
libraries, but now the `mirage` tool maintainer has to look around and rev all 
the libraries if they modify the main.ml code generation (for example, to add 
optional profiling hooks or something similar).

I'm not really convinced the code motion would be worth it at this stage vs 
(for example) prototyping a metacaml-based staging framework and seeing what a 
printf-free tool would look like.

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