Re: [Qemu-devel] Re: optional feature

[Anthony Liguori <anthony@codemonkey.ws>]

Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>>>> If instead we would only save/load the part of state if
>>>> the knob is set, we won't have a problem.
>>>>         
>>> The rtc device happens to support an optional feature by splitting 
>>> the  optional bits into a separate section.  Not every device does 
>>> this  though so if you want to convert other devices to this style, 
>>> you'll  break their backwards compatibility.
>>>
>>> The mechanisms are functionally the same.  One is no more 
>>> expressive  than the other.
>>>     
>>
>> Yes, separate devices variant is more expressive.
>>   
>
> Not when you consider my proposed syntax:
>
> .fields = (VMStateField []) {
>  VMSTATE_BOOL(td_hack, RTCState, (VMStateField[]){
>       VMSTATE_INT32(irq_coalesced, RTCState),
>       VMSTATE_INT32(period, RTCState),
>       VMSTATE_END_OF_LIST()}),
> }
>
> You could clearly encode this on the wire as a separate section.  You 
> could autogenerate the name as "rtc-td_hack".  It won't be backwards 
> compatible for save but that's okay.  We can hack things together to 
> make it backwards compatible on load.
>
> I don't like this as a wire format though.  The point though is that 
> if we get the VMState syntax right, then we can make whatever changes 
> down the road we need.
>
>> 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.
>>   
>
> The real argument is against linear versioning.  The whole "optional 
> feature" thing is almost orthogonal.
>
> If we want to support downstream versioning, then I think we should 
> attack that problem properly instead of shoe horning it via "optional 
> features".  This would involve introducing a v4 of the savevm protocol 
> that allowed for a minor versions of device state.  QEMU would always 
> set the minor version to 0.  If downstream decides to introduce 
> changes, they can bump the minor version for a device.  We can also 
> add a minor version to the savevm protocol itself along with a vendor id.

Scratch the savevm protocol minor number.  We need to properly support 
multiple vendor ids and minor numbers.  Otherwise, if you have multiple 
down streams, you could never migrate from the 2-level downstream to 
upstream.

Regards,

Anthony Liguori