On Wed, Dec 02, 2020 at 10:30:11AM +0100, Paolo Bonzini wrote:
> 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 still disagree on the "all about" part even for internal usage.
But this shouldn't really matter for this discussion, I guess.
>
> > 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).
It is a problem if it requires manually converting existing code
defining CPU properties and we don't have a transition plan.
>
> -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' }?
>
Would a -device conversion also involve non-user-creatable
devices, or would we keep existing internal usage of QOM
properties?
Even if it's just for user-creatable devices, getting rid of QOM
property usage in devices sounds like a very ambitious goal. I'd
like us to have a good transition plan, in addition to declaring
what's our ideal end goal.
> 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
>
--
Eduardo
