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