qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Jiri Denemark" <jdenemar@redhat.com>,
	qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 3/6] target-i386: Register QOM properties for feature flags
Date: Wed, 8 Apr 2015 17:36:01 +0200	[thread overview]
Message-ID: <20150408173601.5c39de92@nial.brq.redhat.com> (raw)
In-Reply-To: <20150408150126.GV7031@thinpad.lan.raisama.net>

On Wed, 8 Apr 2015 12:01:26 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Wed, Apr 08, 2015 at 04:09:32PM +0200, Igor Mammedov wrote:
> > On Wed, 08 Apr 2015 14:24:35 +0200
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 
> > > 
> > > 
> > > On 08/04/2015 14:20, Eduardo Habkost wrote:
> > > >> > it would be better to create generic bit property and replace above code with it
> > > >> > something similar to object_property_add_uint32_ptr()
> > > > object_property_add_*_ptr() adds read-only properties, and I didn't want
> > > > to make object_property_add_bit_ptr() inconsistent with the other
> > > > functions. But maybe it is better to have an inconsistent but reusable
> > > > API than making the new code non-reusable by keeping it inside
> > > > target-i386/cpu.c. I will give it a try.
> > > 
> > > add_*_ptr() is read-only because read-only properties do not require
> > > validations (at least that's the common case).  So I think the
> > > inconsistent API is worse than a local one.
> > I've had on my todo list adding add_*_ptr_RW() variants
> > because in common case there isn't any need in validation and
> > with current API we are forced to duplicate custom setter/getter
> > every time for trivial type.
> > For example properties like "level" or "xlevel".
> > 
> > The same goes for generic bitmap setter (i.e.) without validation,
> > which is what we need in this case. We [could] do validation at realize
> > time when it's possible to analyze combination of feature flags.
> 
> Even if no property value validation is done at the setter, we still
> want to prevent the property from being changed after realize (which is
> something I forgot to do in this patch, and we forgot to do on most
> X86CPU setters).
Yep, the same goes for every generic setters in current API
since realize is device specific thingy that's why it's supported by
static properties only now.
We should have something like Stefan's object_property_add_link(...,*check,...)
but for generic properties.

  reply	other threads:[~2015-04-08 15:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-07 20:46 [Qemu-devel] [PATCH 0/6] target-i386: Feature properties, sample script for -global/-readconfig Eduardo Habkost
2015-04-07 20:46 ` [Qemu-devel] [PATCH 1/6] target-i386: Move error handling to end of x86_cpu_parse_featurestr() Eduardo Habkost
2015-04-08  8:31   ` Paolo Bonzini
2015-04-07 20:46 ` [Qemu-devel] [PATCH 2/6] target-i386: Remove underscores from feature names Eduardo Habkost
2015-04-07 20:46 ` [Qemu-devel] [PATCH 3/6] target-i386: Register QOM properties for feature flags Eduardo Habkost
2015-04-08  8:30   ` Paolo Bonzini
2015-04-08 11:06     ` Eduardo Habkost
2015-04-08 12:53       ` Andreas Färber
2015-04-08 11:36   ` Igor Mammedov
2015-04-08 12:20     ` Eduardo Habkost
2015-04-08 12:24       ` Paolo Bonzini
2015-04-08 14:09         ` Igor Mammedov
2015-04-08 15:01           ` Eduardo Habkost
2015-04-08 15:36             ` Igor Mammedov [this message]
2015-04-07 20:46 ` [Qemu-devel] [PATCH 4/6] target-i386: Make "level" and "xlevel" properties static Eduardo Habkost
2015-04-07 20:46 ` [Qemu-devel] [PATCH 5/6] target-i386: X86CPU::xlevel2 QOM property Eduardo Habkost
2015-04-08  8:31   ` Paolo Bonzini
2015-04-07 20:46 ` [Qemu-devel] [PATCH 6/6] scripts: x86-cpu-model-dump script Eduardo Habkost

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=20150408173601.5c39de92@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=pbonzini@redhat.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).