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
