qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Marcel Apfelbaum <marcel.a@redhat.com>
Cc: imammedo@redhat.com, peter.crosthwaite@xilinx.com,
	qemu-devel@nongnu.org, anthony@codemonkey.ws, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH] qom: add object_property_is_set
Date: Tue, 18 Feb 2014 18:49:48 +0100	[thread overview]
Message-ID: <53039D3C.8050802@suse.de> (raw)
In-Reply-To: <530397BD.6090905@redhat.com>

Am 18.02.2014 18:26, schrieb Paolo Bonzini:
> Il 18/02/2014 18:11, Marcel Apfelbaum ha scritto:
>> It is used to replace qemu_opt_get_bool that provides a
>> parameter for a default value. In this case we need to
>> differentiate "no value" from "false."
> 
> But what would the getter return in that case?  If possible, it's better
> to initialize to the default value in an instance_init method.

Another issue I see is that it's currently a valid use case to use a
setter in instance_init to set default values. Doing so would flag the
property as set with this patch.

To me it sounded like a concept similar to component-oriented IDEs where
non-default values are shown in bold. We'd need a QMP API for that
however, and we'd need to reset properties in instance_post_init to
unset then (globals would be considered unset in that case).

Another aspect is that dynamic properties are slightly awkward, if we
think of setting the rtc, which then advances and reads back differently.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2014-02-18 17:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 16:46 [Qemu-devel] [PATCH] qom: add object_property_is_set Marcel Apfelbaum
2014-02-18 16:51 ` Paolo Bonzini
2014-02-18 17:11   ` Marcel Apfelbaum
2014-02-18 17:26     ` Paolo Bonzini
2014-02-18 17:49       ` Andreas Färber [this message]
2014-02-19  7:11         ` Marcel Apfelbaum
2014-02-19  7:03       ` Marcel Apfelbaum

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=53039D3C.8050802@suse.de \
    --to=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=imammedo@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --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).