[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Configuring onboard devices (was: Failing property setters + hardwir
From: |
Daniel P . Berrangé |
Subject: |
Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) |
Date: |
Thu, 30 Apr 2020 11:53:03 +0100 |
User-agent: |
Mutt/1.13.3 (2020-01-12) |
On Thu, Apr 30, 2020 at 11:45:40AM +0100, Peter Maydell wrote:
> On Thu, 30 Apr 2020 at 11:34, Daniel P. Berrangé <address@hidden> 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 :|
- Re: Failing property setters + hardwired devices + -global = a bad day, (continued)
- Re: Failing property setters + hardwired devices + -global = a bad day, Daniel P . Berrangé, 2020/04/29
- Re: Failing property setters + hardwired devices + -global = a bad day, Markus Armbruster, 2020/04/30
- Re: Failing property setters + hardwired devices + -global = a bad day, Peter Maydell, 2020/04/30
- Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Markus Armbruster, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30
- Re: Configuring onboard devices, Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Daniel P . Berrangé, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Peter Maydell, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day),
Daniel P . Berrangé <=
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day), Mark Cave-Ayland, 2020/04/30
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30