Re: [RFC 4/6] migration: Deprecate -incoming <uri>

[Paolo Bonzini]

On 6/12/23 22:51, Juan Quintela wrote:
> > Shall we just leave it there?  Or is deprecating it helps us in any form?
> See the patches two weeks ago when people complained that lisen(.., num)
> was too low.  And there are other parameters that work the same way
> (that I convenientely had forgotten).  So the easiest way to get things
> right is to use "defer" always.  Using -incoming "uri" should only be
> for people that "know what they are doing", so we had to ways to do it:
> - review all migration options and see which ones work without defer
>    and document it
> - deprecate everything that is not defer.

"-incoming <uri>" is literally the same as running "migrate-incoming"
as the first thing on the monitor:

    if (incoming) {
        Error *local_err = NULL;
        if (strcmp(incoming, "defer") != 0) {
            qmp_migrate_incoming(incoming, &local_err);
            if (local_err) {
                error_reportf_err(local_err, "-incoming %s: ", incoming);
                exit(1);
            }
        }
    } else if (autostart) {
        qmp_cont(NULL);
    }

It's the only piece of code which distinguishes "-incoming defer" from
"-incoming <uri>".

So I'm not sure what the problem would be with keeping it?  The issue is
not how many features the command line has, but how they're implemented.
If they're just QMP wrappers and as such they're self-contained in
softmmu/vl.c, that's fine.

In fact, even for parameters, we could use keyval to parse "-incoming" and
set the parameters in the same place as above.  That would remove the need
for "-global migration".

Paolo