[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Configuring onboard devices (was: Failing property setters + hardwir
From: |
Mark Cave-Ayland |
Subject: |
Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) |
Date: |
Thu, 30 Apr 2020 11:54:04 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 30/04/2020 11:45, 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.
>
> 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
Certainly with the machines that I work on the QOM paths can't be guaranteed to
be
stable: a good example would be how over time people have fixed up the macio
device
child devices with refactoring.
So if I had a command line that used a QOM path to connect a chardev to the
on-board
serial port then this change would have caused all of the previously documented
examples out on the internet to fail :/
That's why I'm more keen to go with using aliases as per my previous email
since then
it doesn't matter if the QOM tree structure (accidentally) changes.
ATB,
Mark.
- Re: Failing property setters + hardwired devices + -global = a bad day, (continued)
- 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, 2020/04/30
- Re: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day),
Mark Cave-Ayland <=
- Re: Configuring onboard devices, Markus Armbruster, 2020/04/30