Re: [MirageOS-devel] [ANN] IPv6 on Mirage!

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 20 Nov 2014, at 07:13, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:

>>> fwiw, and without fully understanding your point 2 below, i think that 
>>> having all the type signatures baked into a single library is also rather 
>>> clumsy... modularity FTW! (when supported by assemblage perhaps ;)
>> 
>> Agreed, but as noted, there's a design tradeoff required.  Putting type 
>> *signatures* into a library is dependency free (i.e. mirage doesn't depend 
>> on the entire universe of mirage libraries).  We can indeed split out the 
>> type signatures into libraries, but this will take some time and is a lesser 
>> concern to me than ensuring that IPv6/SSL/Vchan/Ctypes all hit the trunk as 
>> soon as possible.
> 
> Also, multiple implementations, living in different opam packages, might 
> satisfy the same signature. In that case, it is not properly clear where that 
> signature should leave. The answer is probably in an other independent opam 
> package.
> 
> So that means:
> 
> foo-type: the definition of the mirage FOO signature
> foo: the functors for FOO. Depend on foo-type as we want to check 
> signature/implementation matching at compile time. Depends on bar-type, 
> baz-type, etc...
> foo-unix: the implementation of FOO for unix. Depends on foo.
> foo-xen: the implementation of FOO for xen. Depends on foo.
> foo-mirage: the implementation of the combinators for foo-type. Depends on 
> foo-type. Might add a dependency on a specific versions of foo-unix and 
> foo-xen if the right combinators are used when used in a config.ml. For each 
> new versions of foo-unix and foo-xen, we need to upgrade the constraints 
> (which might be painful) to ensure backward-compatibility. Or we can have 
> open constraints, and do a minor release with the right updated constraints 
> before bumping the major version number.
> 
> Then when you want to use foo in your project:
> 
>     $ opam install foo-mirage
> 
> In your "config.ml":
> 
>     open Mirage (* to load the basic combinators *)
>     open Foo_mirage (* to load the combinators for foo *)
>     let main = foreign "Make" (foo @-> job)
> 
> And finally:
> 
>     $ mirage configure [--xen]
> 
> will install either foo-unix or foo-xen automatically, depending on having 
> [--xen] or not on the command-line (as the mirage tool does currently).

cool-- that seems to make sense.

i guess implementing all that mostly requires restructuring existing code plus 
build system hackery for the library so that the different packages become 
build/install targets?

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