From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmxiO-0005Pf-It for qemu-devel@nongnu.org; Sun, 13 Sep 2009 18:38:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmxiK-0005K6-1C for qemu-devel@nongnu.org; Sun, 13 Sep 2009 18:38:36 -0400 Received: from [199.232.76.173] (port=34277 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmxiJ-0005K3-ST for qemu-devel@nongnu.org; Sun, 13 Sep 2009 18:38:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64150) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmxiJ-00067F-DF for qemu-devel@nongnu.org; Sun, 13 Sep 2009 18:38:31 -0400 From: Juan Quintela In-Reply-To: <9A1E60B6-5678-4289-91FF-1CC1EB7D6F61@nokia.com> (Juha Riihimaki's message of "Sat, 12 Sep 2009 19:49:06 +0200") References: <498439EA-7D59-4E25-BD33-26AB8F124388@nokia.com> <9A1E60B6-5678-4289-91FF-1CC1EB7D6F61@nokia.com> Date: Mon, 14 Sep 2009 00:35:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 00/20] VMState: port all i2c devices List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juha.Riihimaki@nokia.com Cc: qemu-devel@nongnu.org wrote: > On Sep 11, 2009, at 13:47, ext Juan Quintela wrote: > >>>> - i2c->address now are uint8_t, my review of all uses is that they >>>> are always >>>> used as uint8_t (and that is the type that is passed on the >>>> value). If you know >>>> i2c, please check. Change 0002 looks big, but it is because as I >>>> was >>> >>> I would propose that the address has more than 8 bits to be more >>> future-proof. After all, the bus addressing has already been extended >>> to 10 bits: see http://www.i2c-bus.org/addressing/10-bit-addressing/ >> >> Then we have a field day, and make incompatible versions from now on. >> VMState use typechecking to make sure that what we save/load has the >> same type that the variable. And that was not the case for i2c >> addresses. how many users have old machines saved that they want to >> restore? > > I'm sorry but why is it not possible to start using e.g. 16 bits for > the address in the save states from now on and still keep the ability > to read save states generated with previous versions? I'm okay with > staying on 8 bit addresses only, I would just like to have some solid > rationale behind that decision. It is possible in the Turing sense. It is not possible in the current VMSTate sense. And it is not trivial to do it. Only thing that I can think of is passing version_id to all get functions to be able to decide if address is 8 bit or 16 bit address. This get ugly fast. The other solution that I can think of is adding address_vmstate that is 8 bits (current code), and a new one that is 16 bit. I think this one is a bit better (althought not perfect for any means). In post_load, we do the adjustments (i.e. for older versions, we copy the value to the new value. It does'nt matter how we do it, fields changing size is never going to be pretty. Is 16 bits enough, or it is going to be needed to get more bits (there are not so many address fields, getting them to 32bits shouldn't be such a big deal. Later, Juan.