From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnwNp-0002o4-3s for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:25:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnwNj-0002mE-G2 for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:25:23 -0400 Received: from [199.232.76.173] (port=41193 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnwNj-0002mB-A2 for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13917) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnwNi-0000Dn-RV for qemu-devel@nongnu.org; Wed, 16 Sep 2009 11:25:19 -0400 From: Juan Quintela In-Reply-To: <20090916151143.GB5513@redhat.com> (Michael S. Tsirkin's message of "Wed, 16 Sep 2009 18:11:44 +0300") 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> <20090916151143.GB5513@redhat.com> Date: Wed, 16 Sep 2009 17:25:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: optional feature List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Gleb Natapov , qemu-devel@nongnu.org "Michael S. Tsirkin" 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.