Re: [libvirt] [Qemu-devel] [PATCH 1/2] numa: deprecate 'mem' parameter of '-numa node' option

Daniel P. Berrangé <berrange(a)redhat.com&gt; writes: > On Mon, Mar 04, 2019 at 12:45:14PM +0100, Markus Armbruster wrote: >> Daniel P. Berrangé <berrange(a)redhat.com&gt; writes: >> >> > On Mon, Mar 04, 2019 at 08:13:53AM +0100, Markus Armbruster wrote: >> >> If we deprecate outdated NUMA configurations now, we can start rejecting >> >> them with new machine types after a suitable grace period. >> > >> > How is libvirt going to know what machines it can use with the feature ? >> > We don't have any way to introspect machine type specific logic, since we >> > run all probing with "-machine none", and QEMU can't report anything about >> > machines without instantiating them. >> >> Fair point. A practical way for management applications to decide which >> of the two interfaces they can use with which machine type may be >> required for deprecating one of the interfaces with new machine types. > > We currently have "qom-list-properties" which can report on the > existance of properties registered against object types. What it > can't do though is report on the default values of these properties. Yes. > What's interesting though is that qmp_qom_list_properties will actually > instantiate objects in order to query properties, if the type isn't an > abstract type. If it's an abstract type, qom-list-properties returns the properties created with object_class_property_add() & friends, typically by the class_init method. This is possible without instantiating the type. If it's a concrete type, qom-list-properties additionally returns the properties created with object_property_add(), typically by the instance_init() method. This requires instantiating the type. Both kinds of properties can be added or deleted at any time. For instance, setting a property value with object_property_set() or similar could create additional properties. For historical reasons, we use often use object_property_add() where object_class_property_add() would do. Sad. > IOW, even if you are running "$QEMU -machine none", then if at the qmp-shell > you do > > (QEMU) qom-list-properties typename=pc-q35-2.6-machine > > it will have actually instantiate the pc-q35-2.6-machine machine type. > Since it has instantiated the machine, the object initializer function > will have run and initialized the default values for various properties. > > IOW, it is possible for qom-list-properties to report on default values > for non-abstract types. instance_init() also initializes the properties' values. qom-list-properties could show these initial values (I hesitate calling them default values). Setting a property's value can change other properties' values by side effect. My point is: the properties qom-list-properties shows and the initial values it could show are not necessarily final. QOM is designed to be maximally flexible, and flexibility brings along its bosom-buddy complexity. If you keep that in mind, qom-list-properties can be put to good use all the same. A way to report "default values" (really: whatever the values are after object_new()) feels like a fair feature request to me, if backed by an actual use case.

[...]