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
