From: Juan Quintela <quintela@redhat.com>
To: "Peter A. G. Crosthwaite" <peter.crosthwaite@petalogix.com>
Cc: peter.maydell@linaro.org, aliguori@us.ibm.com,
qemu-devel@nongnu.org, paul@codesourcery.com
Subject: Re: [Qemu-devel] [PATCH] i2c: factor out VMSD to parent class
Date: Tue, 14 Aug 2012 10:27:54 +0200 [thread overview]
Message-ID: <87sjbpx4hh.fsf@elfo.mitica> (raw)
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")
"Peter A. G. Crosthwaite" <peter.crosthwaite@petalogix.com> 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 <peter.crosthwaite@petalogix.com>
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.
next prev parent reply other threads:[~2012-08-14 8:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 8:09 [Qemu-devel] [PATCH] i2c: factor out VMSD to parent class Peter A. G. Crosthwaite
2012-08-14 8:27 ` Juan Quintela [this message]
2012-08-14 8:46 ` Peter Maydell
2012-08-20 2:28 ` Peter Crosthwaite
2012-08-20 10:20 ` Juan Quintela
2012-08-21 4:02 ` Peter Crosthwaite
2012-08-23 11:59 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sjbpx4hh.fsf@elfo.mitica \
--to=quintela@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=paul@codesourcery.com \
--cc=peter.crosthwaite@petalogix.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).