qemu-option: move help handling to get_opt_name_value
commitafd736252f106ec54734d4e412220a978f668430
authorPaolo Bonzini <pbonzini@redhat.com>
Tue, 3 Nov 2020 13:48:11 +0000 (3 08:48 -0500)
committerPaolo Bonzini <pbonzini@redhat.com>
Sat, 23 Jan 2021 20:55:08 +0000 (23 15:55 -0500)
tree4a911bf4aadee42b5abdb9b50d44a9767457bb54
parent63758d1073970db0a98fdf975b77eeb6eb02e30d
qemu-option: move help handling to get_opt_name_value

Right now, help options are parsed normally and then checked
specially in opt_validate, but only if coming from
qemu_opts_parse_noisily.  has_help_option does the check on its own.

opt_validate() has two callers: qemu_opt_set(), which passes null and is
therefore unaffected, and opts_do_parse(), which is affected.

opts_do_parse() is called by qemu_opts_do_parse(), which passes null and
is therefore unaffected, and opts_parse().

opts_parse() is called by qemu_opts_parse() and qemu_opts_set_defaults(),
which pass null and are therefore unaffected, and
qemu_opts_parse_noisily().

Move the check from opt_validate to the parsing workhorse of QemuOpts,
get_opt_name_value.  This will come in handy in the next patch, which
will raise a warning for "-object memory-backend-ram,share" ("flag" option
with no =on/=off part) but not for "-object memory-backend-ram,help".

As a result:

- opts_parse and opts_do_parse do not return an error anymore
  when help is requested; qemu_opts_parse_noisily does not have
  to work around that anymore.

- various crazy ways to request help are not recognized anymore:
  - "help=..."
  - "nohelp" (sugar for "help=off")
  - "?=..."
  - "no?" (sugar for "?=off")

- "help" would be recognized as help request even if there is a (foolishly
  named) parameter "help".  No such parameters exist, though.

Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
util/qemu-option.c