qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 3/7] vl: New qemu_get_machine_opts()
Date: Thu, 04 Jul 2013 18:11:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

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.

Anyway, what do you guys want me to do?

(1) Create empty machine options on the fly (this is what the current
patch does)

(2) Initialize machine options elsewhere

(3) Make QemuOpts consistently treat NULL like empty options (possibly
quite some work)

I don't mind (1) or (2), but (3) feels like a bit more than I bargained
for.  I just want to fix the bug that bit me, not rework QemuOpts.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]