Re: QEMU API cleanup initiative - Let's chat during the KVM call

[Paolo Bonzini <pbonzini@redhat.com>]

On 06/10/20 11:40, Daniel P. Berrangé wrote:
>> Currently we have:
>>
>>     switch (...) {
>>         case QEMU_OPT_...:
>>             /* something has side effects, something is just parsing */
>>     }
>>
>>     init1();
>>     qemu_opts_foreach(something_opts, configure_something);
>>     init2();
>>     qemu_opts_foreach(some_more_opts, configure_some_more);
>>     init3();
>>
>>     enter_preconfig();
>>
>> We should first of all change it to
>>
>>     parse_command_line() {
>>         apply_simple_options()l
>>         qemu_opts_foreach(something_opts, configure_something);
>>         qemu_opts_foreach(some_more_opts, configure_some_more);
>>     }
>>
>>     switch (...) {
>>         case QEMU_OPT_...:
>>         /* no side effects on the initN() calls below */
>>     }
>>
>>     init1();
>>     init2();
>>     init3();
>>
>>     parse_command_line()
>>
>>     enter_preconfig();
>>
>>     more_init_that_needs_side_effects();
>>
>> This way, the parse_command_line() and its qemu_opts_foreach callbacks
>> can become changed into a series of qmp_*() commands.  The commands can
>> be called within the appropriate loc_push() though.
> 
> I feel that both of these approaches are equally broken, as they don't
> honour the order in which arguments are passed by the caller when
> creating resources.

By design, in that I'm only looking at a backwards-compatible approach.

But once you have reached the second step, you can add QMP commands for
each command-line option (that matters), and configure the VM via QMP
commands.  That _will_ honor the order in which commands are executed by
the caller, obviously.

> I'm not convinced that your proposed change takes us in direction, if
> anything it is encoding the current split of parsing vs creation even
> more strongly.

Yes, but it enables the right way too.  Doing things in steps is the
only way to do them.

Paolo