On Mon, 2018-02-05 at 14:30 +1100, Alexey Kardashevskiy wrote: > On 02/02/18 18:37, Markus Armbruster wrote: > > > > Likewise for properties created differently (say with a different type) > > > > in non-default configuration. We can hope that no such beasts exist. > > > > Since properties get created by code, and code can do anything, we're > > > > reduced to hope. Data is so much easier to reason about than code. > > > > > > > > Three building blocks: instantiate, qom-list, destroy. Do we want the > > > > building blocks, or do we want their combination qom-list-properties? > > > > > > Building blocks as QEMU internal helpers to split my > > > qmp_qom_list_properties() into? These are not going to be huge and > > > "destroy" is literally object_unref(obj) which does not seem very useful. > > > Or I missed the point here? > > > > My question is whether the QMP interface should provide the building > > blocks, or only compositions. > > instantiate but not realize? Not sure we have users for that.
We already have scaffolding for dealing with device-list-properties in libvirt, so the implementation of qom-list-properties proposed by Alexey would probably be able to reuse a lot of code and could be integrated very quickly. So there's that. Would there be any other known use case for providing the building blocks? -- Andrea Bolognani / Red Hat / Virtualization
