Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Apr 30, 2020 at 11:45:40AM +0100, Peter Maydell wrote:
> On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > We "merely" need a new query language targetted to QEMU's qtree
> > structure, which we can expose in the CLI that gives unique access
> > to every possible property.
> 
> Past resistance to this has been grounded in not wanting to
> expose the exact arrangement of the qtree as a user-facing
> thing that needs to be maintained for back-compat reasons.

I could be missing a key difference, but I thought we already exposed
the qtree in QMP  via qom-list, qom-get, qom-set ?  Libvirt uses
these commands for reading various properties.  I guess 'qom-set' is
really defining the kind of query string language I was illustrating
already. So mapping qom-set to the CLI as-is would not be worse than
what we already support in QMP

> Eg in your example the i440fx-pcihost sits directly on the
> 'system bus', but this is an odd artefact of the old qbus/qdev
> system and doesn't really reflect the way the system is built
> up in terms of QOM components; we might one day want to
> restructure things there, which would AIUI break a
> command line like

> > To uniquely identify this we can have a string:
> >
> >  /dev[1]/bus[pci/0]/dev[id=balloon0]/bus[virtio-bus]/dev[0]/deflate-on-oom=true

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|