From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1CUl-0001dB-Sk for qemu-devel@nongnu.org; Tue, 14 Aug 2012 04:29:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1CUj-000231-KW for qemu-devel@nongnu.org; Tue, 14 Aug 2012 04:28:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1CUj-00022p-C7 for qemu-devel@nongnu.org; Tue, 14 Aug 2012 04:28:57 -0400 From: Juan Quintela In-Reply-To: <1344931787-27056-1-git-send-email-peter.crosthwaite@petalogix.com> (Peter A. G. Crosthwaite's message of "Tue, 14 Aug 2012 18:09:47 +1000") References: <1344931787-27056-1-git-send-email-peter.crosthwaite@petalogix.com> Date: Tue, 14 Aug 2012 10:27:54 +0200 Message-ID: <87sjbpx4hh.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] i2c: factor out VMSD to parent class Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Peter A. G. Crosthwaite" Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, qemu-devel@nongnu.org, paul@codesourcery.com "Peter A. G. Crosthwaite" wrote: > Hi All. PMM raised a query on a recent series of mine (the SSI series) about > handling VMSD for devices which define state at multiple levels of the QOM > heirachy. Rather than complicate the discussion over in my series im trying to > start the discussion with an existing subsystem - i2c. This patch is a first > attempt at trying to get the VMSD for generic I2C state factored out of the > individual devices and handled transparently by the super class (I2C_SLAVE). > > I have applied the change to only the one I2C device (max7310). If we were going > to run with this, the change pattern would be applied to all I2C devices. > > This patch is not a merge proposal it is RFC only. > > Please review and let us know if this is flawed or not. What needs to be done to > get this multi-level VMSD going? > > I will use whatever review I get to fix my SSI series as well as fix I2C. > > Signed-off-by: Peter A. G. Crosthwaite This series move data from one part to another (obvious), now the questions: - how do you know that one part of the data relates to the same device on the other side? I don't know about i2c, I am hoping for an answer O;-) This will make that the state of the device will be sent in two chunks, so we should make sure that the two chunks ends in the same device. - This makes the change completely uncompatible. What boards use i2c/ssi? My understanding is that it is only used outside of x86(_64), if so, we can live without backward compatibility. We should increase the version numbers. Something like that on addition. static const VMStateDescription vmstate_max7310 = { .name = "max7310", - .version_id = 0, - .minimum_version_id = 0, - .minimum_version_id_old = 0, + .version_id = 1, + .minimum_version_id = 1, + .minimum_version_id_old = 1, And that should make it. - If you ask me, I would very much preffer something like PCI devices, where the 1st field of any specific device is the i2c part. This would achieve two things: * all i2c devices would have the common fields at the beggining * we sent the data for one device in one go, so we will never had trouble making sure that both devices arrive at the same time, in the right order, etc. - I guess there is same reasy why you want to split the device state, it could be on the other series where I haven't read it though. Later, Juan.