From: Alexander Graf <agraf@suse.de>
To: Marcel Apfelbaum <marcel.a@redhat.com>,
Greg Bellows <greg.bellows@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/3] machine: remove qemu_machine_opts global list
Date: Mon, 15 Dec 2014 16:13:25 +0100 [thread overview]
Message-ID: <548EFA95.3080407@suse.de> (raw)
In-Reply-To: <1418274309.15503.47.camel@localhost.localdomain>
On 11.12.14 06:05, Marcel Apfelbaum wrote:
> On Wed, 2014-12-10 at 16:59 -0600, Greg Bellows wrote:
>>
>>
>> On 10 December 2014 at 07:19, Marcel Apfelbaum <marcel.a@redhat.com>
>> wrote:
>> QEMU has support for options per machine, keeping
>> a global list of options is no longer necessary.
>>
>> Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
>> ---
>> hw/core/machine.c | 45 +++++++++++++++++++++++++++++
>> hw/i386/pc.c | 7 +++++
>> hw/ppc/spapr.c | 3 ++
>> vl.c | 84
>> ++++---------------------------------------------------
>> 4 files changed, 61 insertions(+), 78 deletions(-)
>>
>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>> index 19d3e3a..a0ae5f9 100644
>> --- a/hw/core/machine.c
>> +++ b/hw/core/machine.c
>> @@ -291,48 +291,93 @@ static void machine_initfn(Object *obj)
>>
>> object_property_add_str(obj, "accel",
>> machine_get_accel,
>> machine_set_accel, NULL);
>> + object_property_set_description(obj, "accel",
>> + "Accelerator list",
>> + NULL);
>>
> Hi Greg,
> Thank you for your review!
>
>>
>> If this is a common combination of calls would it make sense to create
>> a wrapper routine that just does both of these steps together for
>> readability and convenience? Maybe something like:
>>
>>
>> object_property_add_str_with_desc(obj, "accel", "Accelerator
>> list"
>> machine_get_accel,
>> machine_set_accel,
>> NULL);
> I really thought about it, but one wrapper would not be enough,
> we need also one for object_property_add_bool, object_property_add and so on.
> The code needed would be twice as this one and for the moment this
> series is the only reason for that, maybe is not enough.
>
> If you or anyone else things we should still go for it, I'll be glad to.
Maybe something like this?
#define MACHINE_OPT(name, namestr, desc, type, ...) \
glue(object_property_add_, type)(obj, namestr, \
glue(machine_get, name), glue(machine_set, name), __VA_ARGS__); \
\
object_property_set_description(obj, namestr, desc, NULL);
>
>>
>> object_property_add_bool(obj, "kernel-irqchip",
>> machine_get_kernel_irqchip,
>> machine_set_kernel_irqchip,
>> NULL);
>> + object_property_set_description(obj, "kernel-irqchip",
>> + "Use KVM in-kernel
>> irqchip",
>> + NULL);
MACHINE_OPT(kvm_shadow_mem, "kvm-shadow-mem", "Use KVM in-kernel
irqchip", _bool, NULL);
Not sure it's a great improvement though. I certainly wouldn't mind to
leave it as this patch does it.
Alex
next prev parent reply other threads:[~2014-12-15 15:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 13:19 [Qemu-devel] [PATCH 0/3] machine: dynamic options per machine type Marcel Apfelbaum
2014-12-10 13:19 ` [Qemu-devel] [PATCH 1/3] machine: remove qemu_machine_opts global list Marcel Apfelbaum
2014-12-10 22:59 ` Greg Bellows
2014-12-11 5:05 ` Marcel Apfelbaum
2014-12-11 14:57 ` Greg Bellows
2014-12-15 15:13 ` Alexander Graf [this message]
2014-12-15 15:20 ` Paolo Bonzini
2014-12-10 13:19 ` [Qemu-devel] [PATCH 2/3] vl.c: simplified machine_set_property Marcel Apfelbaum
2014-12-11 17:49 ` Greg Bellows
2014-12-10 13:19 ` [Qemu-devel] [PATCH 3/3] vl.c: add HMP help to machine Marcel Apfelbaum
2014-12-15 15:16 ` Alexander Graf
2014-12-15 15:20 ` Daniel P. Berrange
2014-12-15 19:24 ` Marcel Apfelbaum
2014-12-15 15:14 ` [Qemu-devel] [PATCH 0/3] machine: dynamic options per machine type Alexander Graf
2014-12-15 17:24 ` Peter Maydell
2014-12-15 17:33 ` Alexander Graf
2014-12-15 17:55 ` Greg Bellows
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=548EFA95.3080407@suse.de \
--to=agraf@suse.de \
--cc=greg.bellows@linaro.org \
--cc=marcel.a@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).