On Thu, Oct 29, 2020 at 11:16:27AM +0100, Andrew Jones wrote: > On Mon, Oct 26, 2020 at 01:22:19PM -0400, Eduardo Habkost wrote: > > I've been trying to clean up the qdev property code (to bridge > > the gaps between qdev and QOM, and between QOM and QAPI), and > > I've noticed that TYPE_ARM_CPU is the only remaining user of > > qdev_property_add_static(). > > > > qdev_property_add_static() has a misleading name: it won't > > register a static property. It is actually a hack to use a > > static Property variable (defined using DEFINE_PROP*), but > > register it as a dynamic instance property. > > > > Dynamic instance properties make introspection hard. What can we > > do to get rid of them in TYPE_ARM_CPU? > > > > Can we just register all the properties unconditionally, and > > error out on realize if the requested CPU configuration is > > incompatible with the available CPU features? > > > > The following properties are registered as dynamic instance > > properties at arm_cpu_post_init(): > > "cntfrq", "reset-cbar", "reset-hivecs", "rvbar", "has_el2", > > "has_el3", "cfgend", "vfp", "neon", "dsp", "has-mpu", > > "pmsav7-dregion", "secure-memory", "pmu", "idau", "init-svtor", > > "tag-memory", "secure-tag-memory". > > Hi Eduardo, > > Are properties added at runtime with > > if (this_config_wants_this_property) > object_property_add(...) > > also considered dynamic instance properties? If so, then > arm as many more than the ones listed above. And, if not, > then it should be pretty easy to convert the ones listed > above to this if-want-add pattern.
Yeah, all object_property_add() calls are also dynamic instance properties. Being conditional makes them more difficult to convert to introspectable class properties (unless the condition is a function of class information only). -- Eduardo
