From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpkt7-0004Mb-4s for qemu-devel@nongnu.org; Thu, 29 Sep 2016 19:37:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpkt5-0006FP-MY for qemu-devel@nongnu.org; Thu, 29 Sep 2016 19:37:13 -0400 Received: from ozlabs.org ([2401:3900:2:1::2]:57447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpkt5-0006Ce-59 for qemu-devel@nongnu.org; Thu, 29 Sep 2016 19:37:11 -0400 Date: Fri, 30 Sep 2016 09:33:20 +1000 From: David Gibson Message-ID: <20160929233320.GJ30519@umbus.fritz.box> References: <1475108205-6043-1-git-send-email-david@gibson.dropbear.id.au> <20160929081416.GD5312@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wHh0aNzodMFDTGdO" Content-Disposition: inline In-Reply-To: <20160929081416.GD5312@redhat.com> Subject: Re: [Qemu-devel] [RFC 0/4] QOM class properties - do we need them? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: afaerber@suse.de, peter.maydell@linaro.org, qemu-devel@nongnu.org, pbonzini@redhat.com, armbru@redhat.com, lcapitulino@redhat.com --wHh0aNzodMFDTGdO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > 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. >=20 > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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? >=20 > 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. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --wHh0aNzodMFDTGdO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX7aTAAAoJEGw4ysog2bOSkS0QALH6tZGEeKtrceZd5ihBEcI1 tPeUKpBwyA9M9+6zIkveqTDSDUXau4wC8ptTJy0XJ20QVYQi6P5q+4NTOqqCCJhA UxsbcJoydEMZEmW3Hn6hA9JPQ71dx6o+1AUPl1rim81hCZR2P48rmdXh8f8xIOVP t7/OMxOMZ/56UJEIZyw7nPJJubYseJgkkJqAVpq+pn8U+slD8htpqoi5nEjz+3oN b+yrAWGHVSnotaBd8SBkbRWOunze7yvnR3GVCNOtdgjvJd7PuPvrMkKN8SJXt6U7 ytmg9ayrzfA+tHZQGPlvkfnUhFQH2ms8vHPavmD034l4/IwN7rOAtnpiHZt72X+o pkyuzMyChiXA7e3uqrqxtlDYG1sp0gr4Xpd4HWow7WZudr/31827hDgQ/Hh9vKDy N8z1GAC3J0XLtg/lUn8wdKaU39Il3hndZa3hm1fLcqMKasoRWK9OA4ocFeO2BZoM ZWw2te4T3Mk8WHlavZLIyjFfcjNzGEuyCSO5fNzUJwDDMDCeCDPZm5YLqOM+/syf amv6UXcpCmk/rrKTu6vJrS93m9Dm6Sn2Og7gRDskr4/ptOfSiqSrNCHNIEfSsKaS afLvmiYwzLBPQJt48OZ8fi0PhQitsj+RDa6NoQGeTMbg5couG63N1i0mnoUMXUzH XyWFdbF74xfoQnLZkMXh =5dfJ -----END PGP SIGNATURE----- --wHh0aNzodMFDTGdO--