On Fri, Jun 23, 2017 at 07:18:19PM -0300, Eduardo Habkost wrote:
> 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()?
I did this change on purpose (after AccelClass.global_props is
introduced). The comment above tried to explain it but looks like it's
still not clear enough... The reason is that currently the creation of
migration object is depending on the global properties, so we need to
create the object after register_global_properties(), while the old
migrate_get_current() cannot really be sure of this ordering: it just
creates the object on the first call of the function, but the first
call can be even before register_global_properties(). If so, we'll
have a problem (e.g. Xen compat properties will be missing).
Now this restriction is strictly followed if we create the migrate
object here. If anyone calls migrate_get_current() before
register_global_properties(), there will be an assert, and that should
be treated as a programming error.
Thanks,
--
Peter Xu
