Daniel P. Berrangé <berra...@redhat.com> writes:
> On Mon, Jun 02, 2025 at 10:38:05PM -0300, Fabiano Rosas wrote:
>> Add a QAPI command feature "capabilities" that can be queried by the
>> client to check that the parameters commands now also support
>> capabilities.
>>
>> Signed-off-by: Fabiano Rosas <faro...@suse.de>
>> ---
>> qapi/migration.json | 20 ++++++++++++++++++--
>> 1 file changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/qapi/migration.json b/qapi/migration.json
>> index 5942622ba7..557a9c523e 100644
>> --- a/qapi/migration.json
>> +++ b/qapi/migration.json
>> @@ -776,6 +776,13 @@
>> #
>> # Set various migration parameters.
>> #
>> +# Features:
>> +#
>> +# @capabilities: Indicates this command supports setting the set of
>> +# parameters previously known as capabilities. This means this
>> +# command can (and should) be used instead of the depreacated
>> +# @migrate-set-capabilities.
>> +#
>> # Since: 2.4
>> #
>> # .. qmp-example::
>> @@ -785,7 +792,8 @@
>> # <- { "return": {} }
>> ##
>> { 'command': 'migrate-set-parameters', 'boxed': true,
>> - 'data': 'MigrationParameters' }
>> + 'data': 'MigrationParameters',
>> + 'features': [ 'capabilities' ] }
>>
>> ##
>> # @MigrationParameters:
>> @@ -1110,6 +1118,13 @@
>> #
>> # Returns: @MigrationParameters
>> #
>> +# Features:
>> +#
>> +# @capabilities: Indicates this command supports setting the set of
>> +# parameters previously known as capabilities. This means this
>> +# command can (and should) be used instead of the depreacated
>> +# @migrate-set-capabilities.
>> +#
>> # Since: 2.4
>> #
>> # .. qmp-example::
>> @@ -1125,7 +1140,8 @@
>> # }
>> ##
>> { 'command': 'query-migrate-parameters',
>> - 'returns': 'MigrationParameters' }
>> + 'returns': 'MigrationParameters',
>> + 'features': [ 'capabilities' ] }
>>
>
> Adding QAPI "features" is only needed if there is no other viable
> way to detect existence of the feature. In this case, apps can
> trivially detect the feature by querying the QAPI schema and
> identifying that the MigrationParameters struct has gained a
> load of new fields. So IMHO this patch can be dropped.
>
Oh, ok. I was thinking this would be friendlier to the management layer,
but if it's all the same I'll drop it. Same for the other one in patch
19.
Thanks
