Re: [PATCH V4 09/19] migration: incoming channel

[Markus Armbruster <armbru@redhat.com>]

Markus Armbruster <armbru@redhat.com> writes:

> Steven Sistare <steven.sistare@oracle.com> writes:
>
>> On 12/5/2024 10:23 AM, Markus Armbruster wrote:
>>> Steve Sistare <steven.sistare@oracle.com> writes:
>>> 
>>>> Extend the -incoming option to allow an @MigrationChannel to be specified.
>>>> This allows channels other than 'main' to be described on the command
>>>> line, which will be needed for CPR.
>>>>
>>>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>

[...]

>>> Option -incoming resembles QMP command migrate-incoming.  Differences:
>>>
>>> * migrate-incoming keeps legacy URI and modern argument separate: there
>>>   are two named arguments, and exactly one of them must be passed.
>>>   -incoming overloads them: if @optarg starts with '{', it's modern,
>>>   else legacy URI.
>>>
>>>   Because of that, -incoming *only* supports JSON syntax for modern, not
>>>   dotted keys.  Other JSON-capable arguments support both.
>>
>> Not sure I follow.
>> Could you give me a dotted key example for a JSON-capable argument?
>> Do we care about dotted key for incoming, given the user can specify
>> a simple legacy URI?
>
> A quick grep for the usual parser qobject_input_visitor_new() finds

Correction: qobject_input_visitor_new_str().

> -audiodev, -blockdev, -compat, -display, and -netdev.  Beware, the
> latter two come with backward compatibility gunk.  There's also -device
> and -object, also with backward compatibility gunk.

[...]