qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] i2c: factor out VMSD to parent class


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH] i2c: factor out VMSD to parent class
Date: Mon, 20 Aug 2012 12:28:10 +1000

On Tue, Aug 14, 2012 at 6:46 PM, Peter Maydell <address@hidden> wrote:
> On 14 August 2012 09:27, Juan Quintela <address@hidden> wrote:
>> "Peter A. G. Crosthwaite" <address@hidden> 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.
>
>> - 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.

So this is exactly what I have done in the SSI. Correct me if I am
wrong but it is the same setup as PCI where the VMSTATE_PCI_DEVICE
(VMSTATE_SSI_SLAVE in my case) is the first field. All I need to do is
bump version numbers?

Regards,
Peter

>
> Really I'm just trying to get clarification on how class hierarchies should
> handle vmstate. At the moment any device which is a subclass of i2c
> has a VMSTATE_I2C_SLAVE field corresponding to the element in
> its struct which is its parent object. This seems a bit odd because
> surely the parent class should be responsible for its own save/load?

Yes I agree. Means you have to define the super class in two places
rather than one (one in the class definition and one in the VMSD). The
problem is if people stick to the guns over backwards compatibility
then this proposed cleanup will never happen. So unless we can fix it
globally and bite the bullet on a pritty much a global version number
bump, then we might as well stick with the current system for the sake
of consistency rather than PCI and I2C working one way and SSI using
something completely different.

> I'm also not sure we do this consistently through the whole QOM
> hierarchy.
>

Ditto on getting consistency going, someone is going to have to sign
off on a backwards incompatibility.

Regards,
Peter

> So what I'm after is not necessarily a patch so much as a decision about
> which way this should be handled. This would probably be good to put
> in a section of Anthony's QOM style guide...
>
> -- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]