[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [PATCH v2 00/44] Make qdev static property API usable by any QOM type
Date: Tue, 10 Nov 2020 11:58:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]