Re: Purpose of QOM properties registered at realize time?

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

[...]
> Possibly one could move the code in the devices which creates the
> GPIO array/sdbus/whatever so that it does so in instance_init
> rather than in realize, and then more of these "alias a connection
> through" bits of code could also move to instance_init. But there are
> cases where the GPiO/etc can only be created in realize because
> the number of GPIOs depends on properties of the device and so isn't
> know at instance_init time.

In real hardware, the number of GPIOs and such is fixed.

When modelling a family of related chips, a "number of GPIOs" property
is sometimes convenient.  The property value is not available at
instance_init time.

By delaying GPIO creation to realize, you can create the configured
number.  The GPIO's QOM property becomes dynamic.

To keep the QOM property static, we'd have to provide the maximum number
of properties, and then connect only the configured number to actual
GPIOs.  This arguably goes against the grain of QOMs dynamic design.  I
never liked that part of the design anyway; I strongly prefer data to
code, and static to dynamic.

For purely virtual hardware, the maximum number might be impractically
large, though.

A first class static array property, where the size of the array is part
of the value could perhaps cover this case.