From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mnwu3-00007x-Tl for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:58:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mnwtz-00007X-3h for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:58:43 -0400 Received: from [199.232.76.173] (port=50097 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mnwty-00007U-VF for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:58:38 -0400 Received: from mail-yw0-f172.google.com ([209.85.211.172]:60117) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mnwty-0006J6-Hk for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:58:38 -0400 Received: by ywh2 with SMTP id 2so7236348ywh.27 for ; Wed, 16 Sep 2009 08:58:38 -0700 (PDT) Message-ID: <4AB10B2A.5090306@codemonkey.ws> Date: Wed, 16 Sep 2009 10:58:34 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: optional feature References: <20090916111845.GJ23157@redhat.com> <20090916115726.GL23157@redhat.com> <20090916123535.GM23157@redhat.com> <4AB0F17B.7000107@codemonkey.ws> <20090916141245.GC5287@redhat.com> <4AB0F45A.7000100@codemonkey.ws> <20090916143459.GD5287@redhat.com> <4AB10824.1030904@codemonkey.ws> In-Reply-To: <4AB10824.1030904@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Gleb Natapov , Juan Quintela 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