Markus Armbruster <[email protected]> writes: > Paolo Bonzini <[email protected]> writes: > >> On 10/22/25 12:14, Markus Armbruster wrote: >>> qdev_print_props() retrieves a property's value from its legacy >>> property if it exists. A legacy property is created by >>> qdev_class_add_legacy_property() when the property has a print() >>> method or does not have a get() method. >>> >>> If it has a print() method, the legacy property's value is obtained >>> from the property's print() method. This is used to format PCI >>> addresses nicely, i.e. like 01.3 instead of 11. >>> >>> Else, if doesn't have a get() method, the legacy property is >>> unreadable. "info qtree" silently skips unreadable properties. >>> >>> Link properties don't have a get() method, and are therefore skipped. >>> This is wrong, because the underlying QOM property *is* readable. >>> >>> Change qdev_print_props() to simply use a print() method directly if >>> it exists, else get the value via QOM. >>> >>> "info qtree" now shows links fine. For instance, machine "pc" onboard >>> device "PIIX4_PM" property "bus" is now visible. >> >> It's been many years, but I think the original idea was that dc->props_ >> would be replaced with walking QOM properties. >> >> I'm not opposed to the patch, but it would put the plan in the coffin so I >> thought I'd point that out.
[...] > My proposed solution: bypass QOM, use qdev directly. Quite a bit > simpler. No need for additional comments, I hope. Kills the accidental > external interface. > > A possible future solution: add the concept to QOM. Then we could walk > QOM properties instead of dc->props_. So, it's not quite the coffin, > more like the freezer. > >> In the meanwhile I queued patch 1, which is an obviously good idea. Paolo, are you okay with the freezer? [...]
