qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 3/4] migration/qapi: Replace @MigrateSetParameters with @M


From: Juan Quintela
Subject: Re: [PATCH v3 3/4] migration/qapi: Replace @MigrateSetParameters with @MigrationParameters
Date: Tue, 31 Oct 2023 12:08:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux)

Markus Armbruster <armbru@redhat.com> wrote:
> Peter Xu <peterx@redhat.com> writes:
>
>> On Wed, Oct 11, 2023 at 04:21:02PM +0200, Markus Armbruster wrote:

>> IIRC both of them used to be the goals: either allow compat properties for
>> old machine types, or specify migration parameters in cmdline for easier
>> debugging and tests.  I use "-global" in mostly every migration test script
>> after it's introduced.
>
> You use -global just because it's easier than using monitor commands,
> correct?

It is long history.  But to make things easier I will try to resume.
In the beggining there was no "defer" method, so it was imposible to
setup migration-channels and that kind of information.
So we created that -global migration properties.

Time pass, and we need to fix that for real, because more and more
migration parameters need to be set bofer we start incoming migration.
So we create migration "defer" method.  And now we can set things from
the command line/QMP.

But when one is testing (i.e. migration developers), using the global
property is much easier.

I am always tempted to modify the monitor command line to allow "read
the commands from this file at startup".

> Configuration is almost entirely special (own QMP commands for
> everything), with a little abuse of general infrastructure stirred in
> (-global, compat props).  Having capabilities in addition to parameters
> is a useless complication.  Too many features of questionable utility
> with way too many configuration knobs.

I also remember that one.
In the beggining all migration options were bools.  So we have named
capabilities.  At some point we needed parameters that were not bools,
so we had to get the parameters thing because all the migration code
supposed that the capabilities were bool.

No, I am not defending the choices we made at the time, but that is how
it happened.  To be fair, when I have a new "bool" to add to migration,
I am never sure if I have to add it as a capability or as a parameter
that returns bool.


Later, Juan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]