[Qemu-devel] Re: optional feature

["Michael S. Tsirkin" <mst@redhat.com>]

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.

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

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

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

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

> > 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, each option should be tagged.
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.

> Later, Juan.