It's very hard to make QemuOpts fail. It's also very easy to write command lines that QemuOpts accept but make no sense.
This series deals with three cases: - QemuOpts accepts ids even for options that are meant to be singletons. As a result, a command line option like "-M q35,id=ff" is ignored silently. - QemuOpts simply matches "help" or "?" against the option name to determine whether the user asked for help. Something like "nohelp" or "?=please" will print the help message. - QemuOpts lets you write boolean options in "short form" where "abc" means "abc=on" and "noabc" means "abc=off". This is confusing, since it is not done for the first key=value pair (but only if there is an implied key); it can also be grossly misused, as in the previous example, because it is not type safe. In case you need confirmation, "-device e1000,noid" will create a device with id equal to "off". Unfortunately, this last idiom has found wide use with -chardev (think "server,nowait") and to a lesser extent -spice, so it can only be deprecated. The other two are removed. Patches 1-3 are cleanups. Patches 4-6 deal with the above issues one by one. I have a seventh patch to remove the third argument to qemu_opts_create, but it touches a few dozen files. Paolo Supersedes: <20201105142731.623428-1-pbonz...@redhat.com> Paolo Bonzini (6): qemu-option: simplify search for end of key qemu-option: pass QemuOptsList to opts_accepts_any qemu-option: restrict qemu_opts_set to merge-lists QemuOpts qemu-option: clean up id vs. list->merge_lists qemu-option: move help handling to get_opt_name_value qemu-option: warn for short-form boolean options docs/system/deprecated.rst | 6 ++ include/qemu/option.h | 3 +- softmmu/vl.c | 19 ++--- tests/test-qemu-opts.c | 26 ++++++- util/qemu-option.c | 149 +++++++++++++++++++------------------ 5 files changed, 113 insertions(+), 90 deletions(-) -- 2.26.2
