Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On 01/12/20 23:08, Eduardo Habkost wrote:
> Properties are only a useful concept if they have a use. If
> -object/object_add/object-add can do the same job without properties,
> properties are not needed anymore.
Do you mean "not needed for -object anymore"? Properties are
still used by internal C code (esp. board code),
-device/device_add, -machine, -cpu, and debugging commands (like
"info qtree" and qom-list/qom-get/qom-set).
Yes.
> Right now QOM is all about exposing properties, and having
multiple
> interfaces to set them (by picking a different visitor). But in practice
> most QOM objects have a lifetime that consists of 1) set properties 2) flip
> a switch (realized/complete/open) 3) let the object live on its own. 1+2
> are a single monitor command or CLI option; during 3 you access the object
> through monitor commands, not properties.
I agree with this, except for the word "all" in "QOM is all
about". QOM is also an extensively used internal QEMU API,
including internal usage of the QOM property system.
Yeah, "all about exposing properties" includes internal usage. And
you're right that some "phase 3" monitor commands do work at the
property level (mostly "info qtree", but also "qom-get" because there
are some cases of public run-time properties).
I'm liking the direction this is taking. However, I would still
like to have a clearer and feasible plan that would work for
-device, -machine, and -cpu.
-cpu is not a problem since it's generally created with a static
configuration (now done with global properties, in the future it could
be a struct).
-machine and -device in principle could be done the same way as -object,
just through a different registry (_not_ a huge struct; that's an
acceptable stopgap for -object but that's it). The static aka field
properties would remain as read-only, with defaults moved to
instance_init or realize. But there would be again "triplication" with
a trivial conversion:
1) in the QAPI schema, e.g. 'num_queues': 'int16'
2) in the struct, "int16_t num_queues;"
3) in the realize function,
s->num_queues = cfg->has_num_queues ? cfg->num_queues : 8;
So having a mechanism for defaults in the QAPI schema would be good.
Maybe 'num_queues': { 'type': 'int16', 'default':
'8' }?
I also need to review more the part of this code with respect to the
application of global properties. I wonder if there are visitor tricks
that we can do, so that global properties keep working but correspond to
QAPI fields instead of QOM properties.
Paolo