On Fri, Jun 23, 2017 at 12:46:40PM +0800, Peter Xu wrote:
> Let the old man "MigrationState" join the object family. Direct benefit
> is that we can start to use all the property features derived from
> current QDev, like: HW_COMPAT_* bits, command line setup for migration
> parameters (so will never need to set them up each time using HMP/QMP,
> this is really, really attractive for test writters), etc.
>
> I see no reason to disallow this happen yet. So let's start from this
> one, to see whether it would be anything good.
>
> Now we init the MigrationState struct statically in main() to make sure
> it's initialized after global properties are applied, since we'll use
> them during creation of the object.
>
> No functional change at all.
>
> Reviewed-by: Juan Quintela <quint...@redhat.com>
> Signed-off-by: Peter Xu <pet...@redhat.com>
> ---
> include/migration/misc.h | 1 +
> migration/migration.c | 78
> ++++++++++++++++++++++++++++++++++--------------
> migration/migration.h | 19 ++++++++++++
> vl.c | 6 ++++
> 4 files changed, 81 insertions(+), 23 deletions(-)
>
[...]
> diff --git a/vl.c b/vl.c
> index cdd2ec8..9b04ba7 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4596,6 +4596,12 @@ int main(int argc, char **argv, char **envp)
> */
> register_global_properties(current_machine);
>
> + /*
> + * Migration object can only be created after global properties
> + * are applied correctly.
> + */
> + migration_object_init();
> +
Do we really need this? Can't be we just do:
if (!current_migration) {
current_migration = MIGRATION_OBJ(object_new(TYPE_MIGRATION));
}
inside migration_get_current()?
> /* This checkpoint is required by replay to separate prior clock
> reading from the other reads, because timer polling functions query
> clock values from the log. */
> --
> 2.7.4
>
>
--
Eduardo
