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

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Nov 10, 2020 at 11:58:29AM +0100, Paolo Bonzini wrote:
> 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.

Right, that would require an introspection interface letting us
get the property name for a given struct field + bit.

Anyway, let's get back to this later.

> 
> > > > 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).

This is true if the property array is always declared as static
const.

> 
> 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.

My first goal here is to facilitate (3) below, and allow it to be
done with less effort and less churn.  This series is not
essential to do (3), but I'd like to avoid porting the same code
to a different API 2 or 3 times because we keep introducing new
mechanisms.

> 
> 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.

Can you clarify this item?  Do you mean an external interface, or
internal APIs?

> 
> 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.

Most of them need to be moved to class properties somehow,
because they are externally visible.  The only exceptions I see
are read-only link properties and child properties.

The trickiest ones are object_property_add_alias() (no
class-level equivalent) and object_property_add_*_ptr() (no
usable class-level equivalent).

object_property_add_*_ptr() is what prompted the creation of this
series.  See
https://lore.kernel.org/qemu-devel/20201009160122.1662082-1-ehabkost@redhat.com

-- 
Eduardo