[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Configuring onboard devices
From: |
Markus Armbruster |
Subject: |
Re: Configuring onboard devices |
Date: |
Thu, 30 Apr 2020 16:38:09 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Daniel P. Berrangé <address@hidden> 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é <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
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
- 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é, 2020/04/30
- Re: Configuring onboard devices,
Markus Armbruster <=
- 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