On 4 July 2013 17:11, Markus Armbruster <arm...@redhat.com> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: > >> On 4 July 2013 16:03, Markus Armbruster <arm...@redhat.com> wrote: >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>>> This looks a bit odd -- why are we creating new >>>> options in a function that claims to only be querying >>>> them? >>> >>> So we never return null. If it bothers you, I can initialize the >>> options to empty somewhere else, and assert they exist here. >> >> The other option would be to modify qemu_opt_get and >> friends to accept a NULL QemuOpts* as meaning "return >> the default". > > I considered it, but it's more involved, and it'll sweep accidental null > opts arguments under the carpet (not sure that's worth worrying about). > >> That seems cleaner to me than having >> "machine" opts be a special case. > > "machine" opts are a special case, because unlike most options, they're > a singleton.
So are boot-opts and smp-opts, right? If you deal with "machine" opts as a special case you'll miss those (and any other singleton options we add later). > (3) Make QemuOpts consistently treat NULL like empty options (possibly > quite some work) I think we could reasonably change just qemu_opt_find(), qemu_opt_has_help_opt() and qemu_opt_foreach() to allow NULL; the rationale being that these are the "query" end of the options API rather than the "set" end. The 'set' end needs to provide a non-NULL opts because we can't just create one on-demand. If you don't want to do that then we could have a point in vl.c where we force all our singleton opts to exist. -- PMM
