Re: [PATCH 8/8] hw/gpio/pca955x: Simplify pin and led getters and setters

[Markus Armbruster <armbru@redhat.com>]

Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:

> On 06/11/2026 11:04, Markus Armbruster wrote:
>
>> Pass the index via object_class_property_add() parameter @opaque
>> instead extracting it from the property name.
>> 
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>

[...]

> Interesting. I think I had a similar issue trying to get the index of a 
> gpio when converting one of the hw/adc devices. No objection here, but 
> we should try and be consistent about how we obtain the index in these 
> cases as I can see this coming up frequently.

Yes, consistency is desirable.

Permit me a digression.

QOM is designed to be maximally flexible, at the cost of extra
boilerplate.  It also enables different solutions to similar problems.

Consider properties.  Property accessors get passed the object and a
void *opaque.  Maximally flexible: the object is necessary, and @opaque
can be anything.  In practice, this pushes you towards writing one
bespoke getter/setter pair per property, ignoring @opaque.

When that becomes too cumbersome, people use @opaque however they see
fit.  For instance, the object_property_add_T_ptr() convenience
functions use it to pass a member offset.  But @opaque can be anything,
and this lets people get creative.

Qdev is different: accessors get passed a property descriptor (struct
Property), which (among other things) includes an @offset.  This pushes
you towards writing a single getter/setter pair per kind of property,
using @offset to access the object memory backing the property.  Less
flexible, less freedom, less boilerplate, more consistency.

Since qdev was rebased onto QOM, it uses @opaque to pass the property
descriptor through QOM to qdev accessors.

End of digression.

We should use @opaque for its intended purpose: pass whatever additional
information the getter/setter needs.  We should not abuse the property
name to pass such information.

object_class_property_add_enum() doesn't support @opaque.  Maybe it
should.

We don't have an object_class_property_add_enum_ptr().  Maybe we should.