Am 02.12.2020 um 10:30 hat Paolo Bonzini geschrieben:
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.
Are internal uses mostly just right after object creation, or do we make
a lot of use of them during runtime?
> > 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;"
This one is optional, you can use the QAPI type even in the run-time
state. I guess this goes back to how much separation you want between
the configuration and the internal state.
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'
}?
Defaults have been on the QAPI wishlist for a long time, and everyone
agrees that it would be nice to have them. Maybe it's time to finally
implement them.
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.
Kevin