There are many problems in QEMU related to introspection of features, which Markus has been attacking/slaying for a while. One of the remaining elephants in the corner of the room which I've not seen work on is QOM.
QOM has a nice class/object framework, kind of like GLib's GObject, but with the difference that properties are registered against objects rather than classes. IIRC the rationale for this is that in some cases the properties registered are going to be dynamically decided at runtime, so it isn't possible to statically define them against classes. Now this may well be true of some properties, but there are equally plenty of cases where the properties /are/ invariant and could be registered against classes. There are two core problems with registering properties against object instances: - It is wasteful of memory to duplicate the allocation of ObjectProperty structs against each object instance. When you have N object instances, you have O(N) memory usage, instead of O(1). This is not a problem for objects which are mostly singletons, but there are cases in QEMU where you instantiate many instances of the same class and/or have many properties. - It prevents static introspection. Since the property is only registered in the object initializer, there is no way to programmatically query what properties an object supports without first instantiating it. Taking machine types as an example, if you want to introspect every machine type supported by a QEMU binary you thus have to launch QEMU many times, passing a different -M argument each time. As the number of different machine types & objects increases this quickly becomes impractical. This series thus extends QOM to make it possible to register properties against the classes, in addition to against object instances. When looking up a property, a search will be done starting at the base class, then each subclass in turn, and finally against the object. Names are enforced to be unique across the parent classes for sanity. This only currently supports simple scalar properties where the actual property value storage is managed by the object instance. The object child and object link properties use implicit storage in the ObjectProperty struct's 'opaque' field, so we can't allow those against the class. Solving this is doable, but more work, so is left as an exercise for the future. The first patch adds the neccessary QOM functionality. The following 6 patches then illustrate the fairly trivial conversions of a bunch of objects. The eventual goal ought to be that everything is registered against the class, leaving only the (hopefully few) cases where per-instance properties are truely needed unconverted. This series doesn't attempt to implement introspection either - this would require a new QMP command such as 'qom-list-type-props' to query the properties against classes. I'm not really planning to spend much more time on this myself. I'm just using this series to illustrate how I believe the introspection problem in QOM can be fairly easily addressed. Hopefully this will stimulate some discussion & interest in doing the full job.... Daniel P. Berrange (7): qom: allow properties to be registered against classes hostmem: register properties against the class instead of object rng: register properties against the class instead of object tpm: register properties against the class instead of object cpu: avoid using object instance state in property getter x86-cpu: register properties against the class instead of object machine: register properties against the class instead of object backends/hostmem-file.c | 26 +++--- backends/hostmem.c | 41 ++++----- backends/rng-egd.c | 12 +-- backends/rng-random.c | 10 +-- backends/rng.c | 14 ++- backends/tpm.c | 12 +-- hw/core/machine.c | 193 +++++++++++++++++++-------------------- include/qom/object.h | 44 +++++++++ qom/object.c | 233 ++++++++++++++++++++++++++++++++++++++++++++++-- target-i386/cpu.c | 88 +++++++++++------- 10 files changed, 476 insertions(+), 197 deletions(-) -- 2.4.3
