Re: [Qemu-devel] [PATCH 3/7] vl: New qemu_get_machine_opts()

[Peter Maydell]

On 4 July 2013 17:11, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>
>> On 4 July 2013 16:03, Markus Armbruster <address@hidden> wrote:
>>> Peter Maydell <address@hidden> 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