All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: afaerber@suse.de, peter.maydell@linaro.org,
	qemu-devel@nongnu.org, pbonzini@redhat.com, armbru@redhat.com,
	lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [RFC 0/4] QOM class properties - do we need them?
Date: Fri, 30 Sep 2016 09:06:12 +0100	[thread overview]
Message-ID: <20160930080612.GA17928@redhat.com> (raw)
In-Reply-To: <20160929233320.GJ30519@umbus.fritz.box>

On Fri, Sep 30, 2016 at 09:33:20AM +1000, David Gibson wrote:
> On Thu, Sep 29, 2016 at 09:14:16AM +0100, Daniel P. Berrange wrote:
> > On Thu, Sep 29, 2016 at 10:16:41AM +1000, David Gibson wrote:
> > > QOM has the concept of both "object class" properties and "object
> > > instance" properties.
> > > 
> > > The accessor functions installed for the rarely-used class properties
> > > still take an Object *, so the *value* of such properties is still
> > > per-instance; it's just the *existence* (and type) of the property
> > > that is per-class.
> > 
> > Yes, of course. This is the whole point of class properties. It avoids
> > allocating the same ObjectProperty struct against every object instance
> > which wastes massive amounts of memory in scenarios where there are lots
> > of instances created.
> 
> Ah, that makes sense.
> 
> > > Of course, that's also true in practice for the great majority of
> > > "instance" properties, because they're created identically and
> > > unconditionally for every instance from the per-class instance_init
> > > hook.
> > > 
> > > This also means that the (unused) object_class_property_add_*_ptr()
> > > functions don't make a lot of sense, since they require a fixed
> > > pointer which means the value of such a property would only be
> > > per-class.
> > > 
> > > Given that, is there really any value to supporting the "class"
> > > properties in addition to the "instance" properties?  This series is
> > > an RFC which removes all support for class properties, changing the
> > > few existing users to instance properties instead.
> > > 
> > > Alternatively, if we *don't* want to remove class properties, should
> > > we instead be trying to convert the many, many "instance" properties
> > > whose existence is actually per-class to be class properties?
> > 
> > Practically all instances properties should become class properties
> > as its going to save wasting memory once most are converted.
> 
> Heh, ok.  Well, I'll keep that in mind when I'm adding properties in
> future.  I wonder if there's a way we can better get the word out that
> this is how properties should usually be done.
> 
> That said.. I'm still thinking we should remove
> object_class_property_add_*_ptr().  Those take an actual pointer to
> the value, meaning that it can't have different values per-instance.
> These only create read-only properties, so they're not actually
> dangerous, but they really don't seem very useful.

Yeah, that method seems dubious - my mistake in just copying all
the existing property methods.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

  reply	other threads:[~2016-09-30  8:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-29  0:16 [Qemu-devel] [RFC 0/4] QOM class properties - do we need them? David Gibson
2016-09-29  0:16 ` [Qemu-devel] [RFC 1/4] qcrypto: Remove usage of class properties David Gibson
2016-09-29  0:16 ` [Qemu-devel] [RFC 2/4] s390: Don't use " David Gibson
2016-09-29  0:16 ` [Qemu-devel] [RFC 3/4] tests: Remove tests for " David Gibson
2016-09-29  0:16 ` [Qemu-devel] [RFC 4/4] qom: Abolish " David Gibson
2016-09-29  7:52 ` [Qemu-devel] [RFC 0/4] QOM class properties - do we need them? Paolo Bonzini
2016-09-29  8:14 ` Daniel P. Berrange
2016-09-29 10:12   ` Andreas Färber
2016-09-29 10:21     ` Daniel P. Berrange
2016-09-29 10:23       ` Andreas Färber
2016-09-29 23:36         ` David Gibson
2016-10-04  9:51         ` Kevin Wolf
2016-09-29 23:33   ` David Gibson
2016-09-30  8:06     ` Daniel P. Berrange [this message]
2016-09-29 10:16 ` Andreas Färber
2016-09-29 23:37   ` David Gibson

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=20160930080612.GA17928@redhat.com \
    --to=berrange@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=lcapitulino@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.