[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: optional feature
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] Re: optional feature |
Date: |
Wed, 16 Sep 2009 18:11:44 +0300 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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.
- [Qemu-devel] Re: optional feature, (continued)
- [Qemu-devel] Re: optional feature, Gleb Natapov, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- [Qemu-devel] Re: optional feature, Gleb Natapov, 2009/09/16
- [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- [Qemu-devel] Re: optional feature,
Michael S. Tsirkin <=
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
[Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16