All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] qdev properties vs qom object properties
Date: Mon, 5 Jun 2017 10:36:50 -0300	[thread overview]
Message-ID: <20170605133650.GM4294@thinpad.lan.raisama.net> (raw)
In-Reply-To: <CAFEAcA_pErWnoUh_-fxaBMZB1L=4jYxUXYfx9CA5uVnx0H2_pw@mail.gmail.com>

On Mon, Jun 05, 2017 at 02:10:06PM +0100, Peter Maydell wrote:
> I perpetually get confused about qdev properties vs QOM object
> properties.

You are not alone.  :)

> 
> Why do we have both of these APIs?

I don't know.  Probably because the QOM property API was
introduced, it was just a subset of of the features provided by
qdev properties, so the qdev API had to be kept.


> How do they interact?

qdev properties are implemented on top of the QOM property APIs.
After the properties are registered by qdev code, we can simply
use the QOM APIs to interact with them (to get/set/enumerate
properties).

But qdev provide some extra features[1], that's why we can't
simply replace all code using qdev properties to use the QOM APIs
directly.

[1] Some of the differences I remember:
* qdev properties can be defined declaratively using
  using Property arrays.
* qdev properties allows you to set a default value more clearly
  in the code.
* qdev properties don't require custom getters/setters to be
  written.  You just need to provide the field name (which is
  saved as a field offset by the DEFINE_PROP_* macros).
* qdev setters automatically check if "realized" is true, and
  refuse to change a property after the device is realized.
* some existing code (mostly monitor code, I think) looks for
  qdev properties only, but will ignore other QOM properties.
* A few data types (and their corresponding parsers) are only
  defined as qdev types (PropertyInfo structs), not on the QAPI
  schema.


> Which is the recommended one for new device code?

qdev properties are easier to use, so I recommend using them
unless you need custom getters/setters.


> Do we have a transition plan for old code?

We don't.  I believe we should first make the QOM API as powerful
as the qdev property API.  Then we can replace qdev-specific code
with equivalent QOM code.


> Where should I be looking for the documentation on this?

Good question.  The QOM API is well documented, but the way the
qdev property code interacts with the QOM API is not.


> 
> For a specific example, I see that target/arm is the only code
> using qdev_property_add_static(), but there's no indication
> that the function is deprecated or what the right thing to be
> doing instead is. Any suggestions?

qdev_property_static() is still easier to use than writing custom
getters/setters for object_property_add(), so I don't think we
should deprecate it yet.

-- 
Eduardo

  parent reply	other threads:[~2017-06-05 13:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05 13:10 [Qemu-devel] qdev properties vs qom object properties Peter Maydell
2017-06-05 13:32 ` Paolo Bonzini
2017-06-05 13:39   ` Eduardo Habkost
2017-06-06  7:22   ` Markus Armbruster
2017-06-06  8:48     ` Gerd Hoffmann
2017-06-05 13:36 ` Eduardo Habkost [this message]
2017-06-05 13:44   ` Paolo Bonzini

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=20170605133650.GM4294@thinpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.