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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 17 November 2014 17:02, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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.

I think this is the problem. Once a program is consigned to contraint
hell, there's no easy way to update it incrementally to the new APIs.

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

I'm not sure what you mean by "broken". Some recent examples of
incompatible changes to interfaces we've discussed:

- CONSOLE became a FLOW, changing write and write_all.
- The IP interfaces are changing to support IPv6.
- ETH.write is getting a flags argument for TCP checksum offload.
- Errors changing from variants to exceptions in some places.

The old interfaces aren't exactly broken; we're just adding new
features or cleaning up the API.

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

So the upgrade procedure would then be:

1. Update to new mirage. Everything breaks.
2. Change all code to use DEPRECATED interfaces in all places, so it
will compile again.
3. Start replacing DEPRECATED types with STABLE ones until the upgrade
is complete.

It doesn't seem like an improvement.

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



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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