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

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 30/04/2020 11:45, 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.
> 
> 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.