Re: [Qemu-ppc] [QEMU PATCH v5 4/6] migration: migrate QTAILQ

[Paolo Bonzini]

On 06/10/2016 13:56, Dr. David Alan Gilbert wrote:
>> > Yes, it's sickening but that's what you do to honor backwards 
>> > compatibility.
> Actually, that's not *that* bad an idea.
> 
> Lets go with Jianjun's structure for the moment; we can always expand on it.
> 
> It seems we have ~3 concepts that feel partially independent:
> 
>     a) The format of the loop on the wire (eg one byte per iteration, 0 
> terminates)
>     b) The way the list is represented (QTAILQ, simple array, device specific 
> linked-list)
>     c) The data gathered in each iteration
>     d) The allocation of (c)
> 
> This patch has a,b,d all wrapped up together in the get/put functions -
> where I was hoping to find a way to separate them a bit so that we
> could say; I want a loop, with this format, into this data structure, using 
> this allocator.

Yes, the sickening part is when the format of the loop intersects with
the format of the datastructure.

I agree with moving the allocator out of VMStateInfo and back into
VMStateField, but only as long as VMStateAllocator could replace other
VMS_* flags.

I'm not sure about the value in separating (a) and (b), but we can do
things one step at a time.

By the way, regarding this:

> The other possibility is just to bump the version and make the SCSI
> request flag a separate byte after the "is there another entry" byte.

There is another way to do it that is much more backwards-compatible.
Choose a "default" value of retry corresponding to what QEMU encodes as
a "1".  If it's different, use a subsection to encode that.  Migration
from old to new will fail if the wrong value of retry is used, because
it will see a 2 where the QTAILQ loop expects a zero or one.  Migration
from new to old will fail if the wrong value of retry is used, because
it will see a subsection header where the QTAILQ loop expects a zero or one.

I think this is acceptable, and it would only affect migration of USB
storage devices.

Paolo