[Qemu-devel] Re: optional feature

[Juan Quintela <quintela@redhat.com>]

"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Sep 16, 2009 at 04:53:47PM +0200, Juan Quintela wrote:
>> > It is more modular.  With optional features A B C, versioning can not
>> > support saving only A and C but not B.  This is bad for example for
>> > backporting features between versions: if C happened to be introduced
>> > after B, backporting C will force backporting B.
>> 
>> No problem again.
>> You backport, and you add to the state both B and C.  You just don't
>> care about B values.  I leave you a name for them:
>> 
>> reserved0
>> reserved1
>> reserved2
>> 
>> And you are done.
>
> Not really. When you save, B has an invalid value.
> Load it in upstream qemu, boom.

You are donig the backport or only C, you have to be able to put
sensible values here.

>> And what is worse, what happens when you have to upgrade B and C with
>> new fields?  Now you have:
>> 
>> A, B, B', C, C'
>> 
>> And what options are valid?  How you differentiate between B and B', C
>> and C', a version number?
>
> Each is a new feature.
> If B' relaces B, then do not store B, store only B'.

Backward compatibility was the whole game, do you remember?  If I can
remove backward compatiblity, at least half of the problems dissapear.

>>  We are back at stage 1?
>> 
>> And how many features do you support?  Exponential again.
>
> Nothing exponential. Test with each feature on and off, you are done.

1 features 2 test
2 features 4 tests
4 features 16 tests

it looks very exponential to me.  You need to test all combinations.
You are the one wanting to be able to use all combinations.

>> With linear version numbers you are going to have:
>> 
>> A
>> A+B
>> A+B+C
>> A+B'+C
>> A+B'+C'
>
> This is exponential in the number of combinations you need to code up.

No, you only code the ones that I showed.  You are done.

>> (you can switch the 2 last ones depending the order in which changes
>> happen).  And that is it, no exponential cases again.  we added 4
>> features and we have 4 new versions.  It looks very linear to me.
>> And we can still load all the previous versions.
>> 
>> > But you can support it if you put each one in a migration container.
>> 
>> My opinion: We don't even want to think about this.
>> 
>> 
>> > if you are not saving irq state, it's better
>> > to skip the array that create a 0 size array.
>> 
>> Why?
>
> Because of what I said below: it does not work for non-arrays.

For non arrays it is easier, you just put the value there.  No problem
at all.  You are saving a 512MB (at minimum) image, believe me, 20 bytes
more/less are not going to matter.

>> > The former works for non-array fields, the later does not,
>> > and you have to invent a separate valid bit.
>> 
>> VMStateDescription, think of it as a contract.  Would you like that the
>> other part would be able to insert whole paragraphs when he wants?
>> Without ever telling you that it changed (i.e. same version).
>
> Yes, it has to tell me

How, where?

>, each option should be tagged.

how?

> I see a new paragraph, I do not recognize it, I abort.

>> I don't think so.  I am sure I would preffer that it will told me
>> clearly that contract changed (new version), and the changes are this,
>> this and this.
>
> It does not though. The connection between versions and
> sets of features is scattered over the code.
> Instead, the format should be self-documenting.

Wait, I thought you were the one wanting backward compatibility.  Now,
we want a different format.  And how are you going to send that to an
old version?  Format is what it is.  I can't understand your switch
here, sorry.

1st: you want to send blobs, and you make sure that you understand what
     you send, vmstate is just a transport.
2nd: you want to be able to pick what features you want/don't want, set
     the save version number, and expect that the other side is able to
     understand.  You explicitely wanted to be able to send for a newer
     qemu version in a device with more features to an old qemu version
     with an device with less features.
3rd: Now you want a different format, where backward compatibility
     obviously dissapear.

Sorry, I can't follow you.

Later, Juan.