Re: [PATCH v10 3/8] qapi: add backend-transfer migration parameter

[Markus Armbruster <armbru@redhat.com>]

Peter Xu <peterx@redhat.com> writes:

> On Sun, Feb 01, 2026 at 07:19:55PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>>  # @migrate-set-parameters:
>> @@ -1004,6 +1005,13 @@
>>  #     is @cpr-exec.  The first list element is the program's filename,
>>  #     the remainder its arguments.  (Since 10.2)
>>  #
>> +# @backend-transfer: Enable backend-transfer feature for devices that
>> +#     supports it.  In general that means that backend state and its
>> +#     file descriptors are passed to the destination in the migraton
>> +#     channel (which must be a UNIX socket).  Individual devices
>> +#     declare the support for backend-transfer by per-device
>> +#     backend-transfer option.  (Since 11.0)
>
> I still think it'll be nice to either have "local" in the name of parameter
> or at least document it with crystal clear terms.
>
> I used to suggest fd-passing, but maybe you wanted to emphasize there's
> more than fds to be migrated at least for tap? Then it can still be
> "local-backend-transfer", because nobody stops a device to transfer backend
> states in a remote migration either.. so "backend-transfer" seems to also
> work for remote migrations, but it is not.
>
> Or at least mentioned explicitly in the comment, saying this is a local
> migration / upgrade.

Documenting the restriction is a must regardless of naming.  The
proposed text does document it, but only indirectly: "(which must be a
UNIX socket)".  Could be improved, I guess.

Capturing the restriction in the name might help.  But it also makes the
name longer.  Feels like a matter of taste to me.  You guys decide :)

> If you could at least update the doc on the locality attribute for the
> migration (one way or another..), feel free to take:
>
> Acked-by: Peter Xu <peterx@redhat.com>
>
> If you decide to rename, that's even better.
>
> Thanks,