Re: [MirageOS-devel] V1 vs V2 mirage-types

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 17 Nov 2014, at 16:51, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> 
> 
> 
> Le lundi, 17 novembre 2014 Ã 17:26, Anil Madhavapeddy a Ãcrit :
> 
>> Perhaps we should think in terms of STABLE and DEVEL, instead of V1
>> and V2 (which imply a V3, V4, etc). If we just have two interfaces,
>> then the class of breakages are well understood:
>> 
>> - A change in a STABLE interface requires an immediate rev to all the
>> packages that use the old interface, or else they'll simply be
>> Mirage incompatible. Old implementations will be consigned to the
>> depths of constraint hell so they will not be selected with the
>> latest Mirage version.
>> 
>> - DEVEL packages represent work in progress interfaces, and libraries
>> should do their best to keep up with the interface. When we're happy
>> that a certain interface is behaving well, it can be promoted to
>> STABLE.
> 
> I'm not sure this scheme really answer the question; V1 FS used to be STABLE, 
> it's no longer. How to you remove things from STABLE.

If the interface is broken (which is presumably why it's being deleted, and
not modified), just delete it entirely and rev all the depending libraries
as you would for a modification.  You could move it to a DEPRECATED space
for archival, as you note (but this would still break libraries that were
parameterised on STABLE.THEINTERFACE).

> 
> One question that still bugs me (due to my mirage ignorance) is can V1 FS 
> still be used in mirage V2 ? If that's the case these signatures are not 
> really versions, just different ways of interacting with the system (some of 
> which may eventually become unsupported).


Most of the time, the module interfaces are passthrough and used in two places:

- the libraries implementing them refer to V1.FS as the signature they
  export.  Since this is structural, a future rev can try to stay compatible
  by satisfying V1 and V2. 

- the unikernel application is parameterised as a functor over V1.FS.

The only place where Mirage needs to 'know' about interfaces is the 
configuration
phase that generates main.ml through an invocation of `mirage configure`.
This is responsible for metaprogramming the config.ml and generating a set
of initialisers for values and glueing them together.

The vast majority of uses here are simply `FOO.connect id >>= fun foo -> 
use_it)`
and so will continue to work.  The problematic ones are the configuration-heavy
backends that have a lot of custom code generation at the configuration phase.

Networking is one such unfortunate example... we'll know soon enough how revving
works when we merge Nicolas' IPv6 networking patches.

-anil



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