From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnwCP-0004se-NZ for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:13:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnwCL-0004m6-Uk for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:13:37 -0400 Received: from [199.232.76.173] (port=46406 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnwCL-0004lq-Of for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:13:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43512) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnwCL-0005ZC-9p for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:13:33 -0400 Date: Wed, 16 Sep 2009 18:11:44 +0300 From: "Michael S. Tsirkin" Message-ID: <20090916151143.GB5513@redhat.com> References: <20090916115726.GL23157@redhat.com> <20090916123535.GM23157@redhat.com> <4AB0F17B.7000107@codemonkey.ws> <20090916141245.GC5287@redhat.com> <4AB0F45A.7000100@codemonkey.ws> <20090916143459.GD5287@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: optional feature List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Gleb Natapov , qemu-devel@nongnu.org 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.