[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list Q
From: |
Andrea Bolognani |
Subject: |
Re: [Qemu-devel] [RFC PATCH qemu] qmp: Add qom-list-properties to list QOM object properties |
Date: |
Wed, 07 Feb 2018 13:18:31 +0100 |
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