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

Reply via email to