Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Apr 30, 2020 at 11:45:40AM +0100, Peter Maydell wrote: >> On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé <berra...@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
We like to pretend QOM introspection is not a stable interface. Except for the parts that have to be, because they're the only way to probe for certain things. We're not telling you which parts, because we have no idea ourselves. >> 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 If we replace qdev paths by QOM paths, the "doesn't really reflect the way the system is built up in terms of QOM components" goes away. However, the "we might one day want to restructure things" argument also applies to QOM. At some point we need to decide which part of the cake to feed to users, and which part to keep for developers to mess with. >> > 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
