qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: remove subsections in fdc and rtl813


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] migration: remove subsections in fdc and rtl8139 and bump versions
Date: Wed, 03 Aug 2011 23:42:40 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Anthony Liguori <address@hidden> wrote:
> On 08/03/2011 04:00 AM, Juan Quintela wrote:

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

I have.  If we are changing a protocol in an incompatible version, we
can remove a lot of warts that current descriptions have.  Not that
Paolo protocol is bad, but if we are going to do some change, adding
things like size, removing previous warts, etc is the way to go.

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

Ok, only IDE is broken, something done if we are not reverting the others.

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

It is not possible to introduce that later.  I very much prefer leave
things as they are, and add an stricter subsection test later.

Later, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]