Re: [PATCH v2 09/10] qom: Allow default values for instance properties

On 11/06/2026 15:17, Daniel P. Berrangé wrote:

> On Thu, Jun 11, 2026 at 03:08:41PM +0100, Mark Cave-Ayland wrote:
>> On 09/06/2026 18:25, Peter Xu wrote:
>>
>>> ObjectProperty allows default value settings via proper setup of
>>> prop->init() and prop->defval.  It currently is only supported in class
>>> properties, not instance properties.
>>>
>>> However, since QOM allows class and instance properties, it should also
>>> allow instance to add properties during instance_init() and allow the
>>> default values to be applied properly for this instance only.
>>
>> Thinking back to the earlier patches, a question that has come up before is
>> whether we should require all properties to be class properties?
> 
> Ideally yes, but we have the classic QEMU problem of a big pile of technical
> debt that would need converting and always more interesting things to work
> on.
> 
> Most is a boring mechanical task, but there are some awkward edge cases
> around dynamically added properties.

That's true, although we already have to handle this given a codebase 
with the history of QEMU. The most important part is often to take the 
decision and enforce it.

For example, we can take the decision today that we all new properties 
must be class properties but if we do, then we also need to ensure that 
all code reviewers are aware of this and enforce it.

That leaves the issue of the existing code. Our normal acceptance 
criteria is does it pass the regression/functional tests, so I don't see 
why we can't aim for that here?

Back to this particular patch, if we want to make the decision that 
class properties are the way forward we can at least ensure that the 
patches is written in a way such that object property support can be 
easily removed later.

>>                                                                    IIRC one of
>> the motivations for this move was to allow schema introspection, but I don't
>> immediately have a reference to the original discussion.
> 
> Better supporting introspection was the original key goal, but also
> reducing memory footprint for classes  which have 100s or 1000s of
> instances registering the same props over & over. Introspection against
> the class means we trivially avoid risk of side-effects from instantiating
> objects and not completing their realization.

That does sounds like another compelling reason :)


ATB,

Mark.