[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: optional feature
From: |
Juan Quintela |
Subject: |
[Qemu-devel] Re: optional feature |
Date: |
Wed, 16 Sep 2009 17:25:11 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
"Michael S. Tsirkin" <address@hidden> 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.
- [Qemu-devel] Re: optional feature, (continued)
- [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, 2009/09/16
- [Qemu-devel] Re: optional feature,
Juan Quintela <=
- 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