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.

I'd argue that legacy properties are a questionable hack to preserve a
specific solution to a problem.

The problem: PCI addresses are integers in C and in QOM.  Makes sense.
But "info qtree" has always displayed PCI addresses in the form DEV.FN,
which also makes sense.

The pre-QOM solution: qdev property method .get() returns the integer,
.print() formats it for humans.  "info qtree" used the latter.

Aside: "format for humans" may well be more widely applicable, if we
care.

The current QOM solution: QOM has no concept "format for humans", it has
only .get().  Instead of introducing the concept, we added "legacy
properties" whose .get() method wraps around qdev's .print() instead of
qdev's .get().

This created yet another accidental external interface.  Fixable the
same way as other accidentally exposed properties: add the means to
restrict access to C.

How legacy properties work and how they're used is less than clear.
Evidence: I was rather confused, and had to dig through quite a bit of
code to unconfuse myself.  I guess that would also be fixable to a
degree with comments.

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.

Thanks!


Reply via email to