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

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

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.

the former means that it ought to be easier to see exactly which libraries 
(potentially version-constrained libraries) are currently supported. the latter 
point means that, when a library is revved, the library maintainer can 
simultaneously update the code generation as required. in combination, it will 
hopefully be easier to add a new implementation of one of the mirage-supported 
types.

notes:

+ we no longer have V1 vs V2 etc. a "version" of mirage is effectively defined 
by the content of the mapping created in step 1 as that's what specifies what 
gets pulled in in response to the content of the `config.ml` and any 
environment-provided settings (command line switches, environment variables). 

+ if we want to update an existing signature, that still requires updating all 
the implementation libraries, so no change there. perhaps any updates required 
to the mirage tool are better contained and more straightforward, perhaps not. 
probably no worse though.

+ if we want to support different versions of a signature in parallel, we just 
have to give them distinct names. but it's at least fairly explicit what's in 
and what's out. if it's a conflict to use both together, then this might 
perhaps be captures by having opam barf when it tries to install two 
conflicting versions of the same library (or two conflicting libraries).

+ this possibly also makes having a "development" branch a simpler matter: 
override entries in that mapping as desired. unless more `'a typ` types or `'a 
impl` implementations of existing `'a typ` types are being added, nothing else 
in the mirage tool should need to change.

+ one problem not addressed but noted is that unit testing of the code 
generation remains a problem, and perhaps is more significant if library 
maintainers are expected to provide this. (from my pov though, this tends 
towards black magic currently anyway so unclear that this is any worse than the 
current state.)

anil also popped in and talked moderately excitedly about meta-ocaml, but i 
don't know that enough to comment. other than it sounded jolly cool and 
something that may be worth investigating to do some of the above in a more 
publishable fashion ;)

so-- how much of that makes any sense, and (thomas) how much did i garble?


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