On 26/08/2026 11:40, Marc-André Lureau wrote:
Hi
On Tue, Aug 25, 2026 at 7:33 PM Mark Cave-Ayland
<[email protected]> wrote:
On 18/08/2026 12:10, Marc-André Lureau wrote:
Hi,
This series connects QOM and qdev properties to the QAPI type system, so
that management tools can discover the QAPI schema type of each object
property.
Today, QOM properties carry a free-form "type" string ("bool", "uint32",
"OnOffAuto", ..) that has no formal link to the QAPI schema exposed by
query-qmp-schema. Management tools must maintain ad-hoc mappings or rely
on naming conventions to figure out how to interpret property values.
This series adds:
- A new QAPITypeInfo struct that pairs a property with its QAPI schema
type name, enum lookup table, and list-element type.
- A QAPI code generator (qapi-type-infos) that emits a QAPITypeInfo
instance for every schema-defined type, including the mapping
between internal C names and the schema name visible to clients.
- A "qapi-type" field in the ObjectPropertyInfo and
ObjectPropertyValue QMP structs, populated from the QAPITypeInfo
when present giving clients a cross-reference into query-qmp-schema
output.
- Conversion of all PropertyInfo definitions from the old
.type/.enum_table strings to the new .qapi_type pointer.
- Replacement of the generic qdev_prop_array with typed per-element
array PropertyInfos, removing the arrayinfo/arrayfieldsize
indirection from struct Property.
- Removal of the deprecated PropertyInfo.type and .enum_table fields,
and of the old object_property_add_enum/add_tm APIs.
Along the way, a few pre-existing type mismatches in property
definitions are fixed, the "struct tm" RTC property is replaced with a
proper QAPI StructTm type etc. Introducing more specific types or a
"typedef" to QAPI could help provide better associated type informations
than plain "str" in many cases, for example.
Comments welcome!
Thanks for quite a substantial piece work: there is quite a lot to pick
through in this series which makes review tricky. If you post a new
version, it might be worth showing an example of the before/after JSON
to help give some context around the changes: however it feels this is
Well, the most significant change is that the query-qmp-schema grew of
about 10% to include types that are not referenced by QMP directly.
And qom-list, qom-list-get, device-list-properties, and
qom-list-properties now return an additional optional "qapi-type"
field to reference the schema types.
Ack. I had a play with query-qmp-schema which probably isn't the most
sensible way to look at the changes...
going in the right direction, since it works towards the goal of
allowing a QMP client to introspect everything it needs to know about
the QAPI type underlying a property.
I've started working through this with a few comments and reviews for
the patches fixing up types: I wonder if the type fixups could be merged
separately to help reduce the size of the series?
Sure, we can cherry-pick the fixes and reduce the new version.
I think it will definitely help since those fixes are easy to review by
themselves and it will help reduce the overall size.
Question: is the eventual aim to deprecate the use of all the non-qapi
object functions? Are there many instances left after this series at all?
QOM itself uses non-qapi functions, but outside of that, none should be left.
I thought that might be the case, but I wasn't sure just from reading
the cover letter. Does it make sense to go all-in and move the non-QAPI
functions to a separate, QOM internal-only header at the end of the series?
ATB,
Mark.
