Re: [PATCH v2 7/9] migration/options: Open code migrate_params_apply

[Fabiano Rosas <farosas@suse.de>]

Peter Xu <peterx@redhat.com> writes:

> On Mon, Feb 02, 2026 at 07:40:59PM -0300, Fabiano Rosas wrote:
>> Remove migrate_params_apply so the logic of setting migration
>> parameters is all in one spot.
>> 
>> Suggested-by: Prasad Pandit <ppandit@redhat.com>
>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> ---
>>  migration/options.c | 33 ++++++++++++++-------------------
>>  1 file changed, 14 insertions(+), 19 deletions(-)
>> 
>> diff --git a/migration/options.c b/migration/options.c
>> index 180ebed51c..733aae51a8 100644
>> --- a/migration/options.c
>> +++ b/migration/options.c
>> @@ -1266,25 +1266,11 @@ bool migrate_params_check(MigrationParameters *params, Error **errp)
>>      return true;
>>  }
>>  
>> -static void migrate_params_apply(MigrationParameters *params)
>> -{
>> -    MigrationState *s = migrate_get_current();
>> -    MigrationParameters *cur = &s->parameters;
>> -
>> -    migrate_tls_opts_free(cur);
>> -    qapi_free_BitmapMigrationNodeAliasList(cur->block_bitmap_mapping);
>> -    qapi_free_strList(cur->cpr_exec_command);
>> -
>> -    /* mark all present, so they're all copied */
>> -    migrate_mark_all_params_present(params);
>> -    QAPI_CLONE_MEMBERS(MigrationParameters, cur, params);
>> -}
>
> I actually like these smaller functions when their name can represent what
> it does (so I read less but know what it is doing faster)..  But yeah if
> both of you like to drop it, I'm OK.
>

Yeah, I tend to agree with you. It's not a big deal anyway.

I want to eventually add a QMP-specific file to migration/ and move all
of the QMP command handlers in there. Having this all in one function
will be (_very slightly_) simpler to move later on.

> Reviewed-by: Peter Xu <peterx@redhat.com>