[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 00/18] qapi/qom: QAPIfy object-add |
Date: |
Wed, 2 Dec 2020 11:38:24 +0100 |
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
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Markus Armbruster, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Kevin Wolf, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Paolo Bonzini, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Kevin Wolf, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Paolo Bonzini, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/01
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Paolo Bonzini, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add,
Kevin Wolf <=
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Paolo Bonzini, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Paolo Bonzini, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Kevin Wolf, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Kevin Wolf, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/02
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Gerd Hoffmann, 2020/12/03
- Re: [PATCH 00/18] qapi/qom: QAPIfy object-add, Eduardo Habkost, 2020/12/03