qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: optional feature


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: optional feature
Date: Wed, 16 Sep 2009 10:58:34 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]