2011/3/1 Juan Quintela <quint...@redhat.com>:
> Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> Hi
>
>> @@ -41,6 +44,9 @@ static const VMStateDescription vmstate_arm_sysctl = {
>> VMSTATE_UINT32(flags, arm_sysctl_state),
>> VMSTATE_UINT32(nvflags, arm_sysctl_state),
>> VMSTATE_UINT32(resetlevel, arm_sysctl_state),
>> + VMSTATE_UINT32(sys_cfgdata, arm_sysctl_state),
>> + VMSTATE_UINT32(sys_cfgctrl, arm_sysctl_state),
>> + VMSTATE_UINT32(sys_cfgstat, arm_sysctl_state),
>> VMSTATE_END_OF_LIST()
>> }
>> };
>
> Three options (about migration):
> - left things as they are and become incompatible without changing versions
> - if you don't care about backward compatibility, just add +1 to all the
> version fields and you are done.
> - add this fields only for the new version.
>
> IMHO 1st one is the worse option. I will go with the middle one (as far
> as I know, nobody on arm uses interversion migration (as far as I know,
> nobody uses migration at all).
OK, so in:
static const VMStateDescription vmstate_arm_sysctl = {
.name = "realview_sysctl",
.version_id = 1,
.minimum_version_id = 1,
I just bump the '1' in both cases to '2' ?
I've only ever used the save/restore for debugging purposes.
We know for certain that nobody can have been doing migration
with versatile platforms before this year, because we only
added save/load support to arm_sysctl.c in December 2010 :-)
(What's the equivalent version-bump that needs to be done
when entries are added to target-arm/machine.c's save and
restore code?)
thanks
-- PMM
