On 09/11/20 21:28, Eduardo Habkost wrote:
I don't know yet what's the best solution for the x86 feature
case. Maybe duplicating the list of feature names would be a
small price to pay to get a static list of properties defined at
compilation time? Maybe we can replace
FeatureWordInfo.feat_names[] with property introspection code
that will find the property name for a given struct field?
The problem is associating the names with the metadata (feature
word/bit). Right now we do that by placing the names in the
feat_names[] arrays, which are indexed by feature word and bit.
If object*_property_add*() is hidden behind a function call or a
`if` statement, it's already too much complexity to me.
You want to remove hiding behind a function call, but why is it any better
to hide behind layers of macros? Just the example you had in your email
included DEFINE_PROP, DEFINE_FIELD_PROP, DEFINE_PROP_UINT32. It's still
impossible to figure out without either parsing or executing C code.
Because we can be absolutely sure the macros (and the property
array) will be constant expressions evaluated at compilation
time.
That's not entirely true. You can always build Property objects
manually in a for loop. (Though at that point you might as well use the
existing API and not the new one).
I think we agree on where _to go_ (schema described outside C code, and
possibly integrated with the QAPI schema). I think neither of us has a
clear idea of how to get there. :) I don't see this series as a step
towards that; I see it more as a worthwhile way to remove boilerplate
from QOM objects.
In my opinion the next steps for QOM (in general, not necessarily
related to the goal) should be to:
1) audit the code and ensure that there are no conditional properties
2) figure out if it makes sense to provide run-time (not compile-time)
introspection of QOM class properties, as either a stable or an
experimental interface, and how it works together with the QAPI
introspection. In particular, whether compound QAPI types can be
matched across QOM and QAPI introspection.
3) figure out if there are any instance properties that can be easily
extended to class properties. In particular, figure out if we can do
class-level property aliasing.
Paolo
