On Mon, Aug 04, 2014 at 05:11:11PM +0100, Alex Bligh wrote:
Michael,
On 4 Aug 2014, at 15:26, Michael S. Tsirkin <mst@redhat.com> wrote:
Unless I'm missing what you are saying?
I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi.
I /think/ you are talking about using the VMSTATE_FOO_TEST macros.
These use field_exists internally.
These are capable of modifying fields within the VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here?
If you want to support lower version IDs, you can just decrease minimum_version_id. field_exists gets the version ID so you can parse different fields depending on the version.
The i8254 change modifies a field which is marked with a minimum version to be a field with no versioning; I guess the route there would be a test function that (somehow) accesses the version of the inbound migration inside it,
Yes, field_exists gets the version value so no problem here.
does the comparison manually, and returns 1 if EITHER the inbound version >=3 or the compatibility thing is set.
Is that what you meant?
I think so, yes.
I'm rather new to this so you may have to lead me a little - apologies.
I was trying to produce code which would be 'obviously correct' in the sense of not breaking the existing pc-1.0 migrations; if playing around with the existing vmstate fields is permissible then clearly I have a few more degrees of freedom.
Yes I think is should be simple but not to the exclusion of maintainability.
I did try modifying the objects live after the command line has been parsed; this doesn't work because the QOM inheritance memcpy's the structs for classes derived from i8254 etc.
Right, just add a new flag for this thing.
-- Alex Bligh