Re: [PATCH v2 00/44] Make qdev static property API usable by any QOM type

[Eduardo Habkost]

On Tue, Nov 10, 2020 at 11:38:04AM +0100, Kevin Wolf wrote:
> Am 09.11.2020 um 21:28 hat Eduardo Habkost geschrieben:
[...]
> > Anyway, If we are the only ones discussing this, I will just
> > defer to your suggestions as QOM maintainer.  I hope we hear from
> > others.
> 
> Well, I expressed my preference for what you're arguing for now, but my
> expertise is more on the QAPI side than on the QOM side, so I can't
> really contribute more arguments in the details than you are already
> doing.

Sorry, I didn't mean to ignore the feedback you had already sent.

Let me rephrase: I was hoping we hear more from you and others.

> 
> In the end, as soon as it's generated code, it won't matter much any
> more what it looks like. But I'm not sure how soon we will be there and
> for the meantime I'll always prefer static data to runtime code.

Agreed.  I really hope we can convince Paolo that properties as
static const data are a desirable feature, and not a crippled
API.

Paolo convinced me that we still need object_class_add_field()
for cases like x86, but I still believe static const arrays of
properties should be the rule for all the rest.

In the meantime, I'll do the following:

I will submit v3 of this series with both
object_class_property_add_field() and
object_class_add_field_properties() as internal QOM APIs.
object_class_add_field_properties() will be used to implement
device_class_set_props().

After that, solving this controversy would be just a matter of
deciding if we want to make object_class_add_field_properties() a
public function or not.

-- 
Eduardo