Re: [Qemu-devel] [PATCH] migration: remove subsections in fdc and rtl8139 and bump versions

[Anthony Liguori]

On 08/03/2011 04:00 AM, Juan Quintela wrote:
> Anthony Liguori<address@hidden>  wrote:
> > So my thinking is to be a bit more conservative.  If we bump the
> > version number for 0.15.0, we make sure that we don't allow new ->  old
> > migration.  We will break old ->  new migration, but we can fix that
> > (including in the stable series) by adding special handling of the
> > previous version.
> >
> > Fixing new->old is the critical bit here.  We can resolve old->new as
> > a stable update.
>
> We are making something that is incompatible.

Indeed.

>  If we don't care about
> breaking 0.14 ->  0.15 migration.  Just add Paolo version, and drop
> altogether the old protocol.  It will give us exactly the same result,
> new versions work, old versions fail.

I don't have a problem with Paolo's new protocol.  In fact, I'm strong 
in favor of applying it to master.  But I don't like the idea of adding 
a new migration protocol with no testing in master before putting it in 
a release.

> > This series was just too late for 0.15.  I can close to suggesting
> > that we delay 0.15 in order to give this time to be tested thoroughly
> > but I think my proposal is a reasonable compromise.
>
> I think it is anything except reasonable.  From my point on view (and I
> am biased), it is the equivalent of finding a corner case broken on
> qcow2 and make all _OLD_ qcow2 images unreadable.  It will work, but it
> is anything except reasonable.  As said, everything uses an fdc.
> Furthermore, the _two_ things that you change don't matter in the big
> scheme of things.  The subsections that fail are the ones that can
> appear in the middle of another section.  The ones that appear at the
> end of a real section work perfectly well with this protocol (a.k.a. the
> ones that are broken are IDE), floppy and rtl8139 are ok with current
> protocol.

I can certainly limit the change to IDE if we think machine, floppy, and 
rtl8139 are safe.

My main concern is fixing the corruption during migration for the 
release.  Once that is fixed, we can revisit compatibility for the 
stable branch (by introducing a compatibility path for the older version).

Regards,

Anthony Liguori

> Later, Juan.