Re: [PATCH 00/54] qom/qdev: associate properties with QAPI schema types
Hi
On Wed, Jul 29, 2026 at 4:43 PM Markus Armbruster wrote:
>
> Marc-André Lureau writes:
>
> > Hi
> >
> > On Wed, Jul 29, 2026 at 11:29 AM Markus Armbruster via qemu
> > development wrote:
> >> Before I dive into individual patches, let me try to work out what the
> >> series does as a whole.
> >>
> >> > This series adds:
> >> > - A new QAPITypeInfo struct that pairs a property with its QAPI schema
> >> > type name, enum lookup table, and list-element type.
> >>
> >> Peeking at the code, I see that ObjectProperty gains a member @qapi_type
> >> pointing to its QAPITypeInfo.
> >>
> >> It is null when the ObjectProperty doesn't have a QAPI type.
> >>
> >> If it's non-null, then ObjectProperty members @name and @type are
> >> redundant with qapi_type.name and .type.
> >>
> >> Correct?
> >
> > Almost. @name is the property name (e.g. "policy"), not the type name.
> > But @type becomes redundant with qapi_type->name when qapi_type is set
> > (object_property_add_qapi derive prop->type from qapi_type->name).
> >
> > Also @type carries additional information for some property kinds that
> > @qapi_type doesn't cover: child and link embed the linked
> > object's QOM type name in the type string. qapi_type can't represent
> > that atm.
>
> Can child and link properties have non-null @qapi_type?
No. Both object_property_add_child() and object_property_add_link()
use the base object_property_add(), not the _qapi variants, so
qapi_type stays NULL.
On the qdev side, qdev_prop_link.qapi_type is &str_type_info, but
create_link_property() calls object_class_property_add_link() which
bypasses that, so the ObjectProperty ends up with qapi_type == NULL
and type = "link".
>
> >> Would "every ObjectProperty has a QAPI type" be a reasonable goal for
> >> the future?
> >
> > Maybe? we would need to address the child<>/link<> gap. At least we
> > can make raw object_property_add() deprecated/static in object.c after
> > this series
>
> Interesting!
>
> >> > - 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.
> >>
> >> Peeking at the code, I find:
> >>
> >> * The type
> >>
> >> typedef struct QAPITypeInfo {
> >> const char *name;
> >> const char *schema_name;
> >> const QEnumLookup *lookup;
> >> const struct QAPITypeInfo *list;
> >> } QAPITypeInfo;
> >>
> >> * A T_type_info for each QAPI type T, including built-in types.
> >>
> >> * T_type_info member @name is T's QAPI name, i.e. "T".
> >>
> >> * T_type_info member @schema_name is T's masked name used in
> >> query-qmp-schema output, null when T is elided there.
> >>
> >> * T_type_info member @list points to TList_type_info when that exists,
> >> else it's null.
> >>
> >> * T_type_info member @lookup points to T_lookup when T is an enum, else
> >> it's null.
> >>
> >> Correct?
> >
> > Yes
> >
> >> > - 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.
> >>
> >> To be precise: when ObjectPropertyInfo member @type is "T", then member
> >> @qapi-type is T_type_info.qapi-type. Correct?
> >
> > @qapi-type is T_type_info.schema_name, the masked name
>
> Right.
>
> >> If .qapi-type is non-null, you can use it to look up precise type
> >> information via QAPI introspection, i.e. query-qmp-schema.
> >>
> >> Correct?
> >
> > Yes
> >
> >>
> >> Possible problem: query-qmp-schema covers only types that are actually
> >> used in QMP. But the above technique additionally wants QOM property
> >> types. I haven't checked what your series does about this, if anything.
> >
> > Most types used as QOM properties are also used by QMP commands. But
> > it's true that types not used by QMP get schame_name = NULL atm.
>
> So the problem is real, and to reap the full benefit of your work, we
> need to solve it. Not necessarily right away.
>
> > Should we have a new pragma? Even if we have conditions, we may end up
> > with unused types in the build, but that shouldn't be a big issue. Or
> > we would need a more complicated several step build.
>
> No need not worry about the how right now.
>
> >> ObjectPropertyInfo is only used with QMP command handlers. It is
> >> computed from ObjectProperty.
> >>
> >> > - Conversion of all PropertyInfo definitions from the old
> >> > .type/.enum_table strings to the new .qapi_type pointer.
> >>
> >> The above is QOM, this is qdev.
> >>
> >> Like ObjectProperty, PropertyInfo gains a member @qapi_type pointing to
> >> its QAPITypeInfo. Howver, this one cannot be null.
> >>
> >> PropertyInfo members @type and @enum_table are dropped, because they are
> >> redundant with qapi_type.type and .lookup.
> >>
> >> Correct?
> >
> > Almost. Every PropertyInfo has a non-NULL
Re: [PATCH 00/54] qom/qdev: associate properties with QAPI schema types
Marc-André Lureau writes:
> Hi
>
> On Wed, Jul 29, 2026 at 11:29 AM Markus Armbruster via qemu
> development wrote:
>> Before I dive into individual patches, let me try to work out what the
>> series does as a whole.
>>
>> > This series adds:
>> > - A new QAPITypeInfo struct that pairs a property with its QAPI schema
>> > type name, enum lookup table, and list-element type.
>>
>> Peeking at the code, I see that ObjectProperty gains a member @qapi_type
>> pointing to its QAPITypeInfo.
>>
>> It is null when the ObjectProperty doesn't have a QAPI type.
>>
>> If it's non-null, then ObjectProperty members @name and @type are
>> redundant with qapi_type.name and .type.
>>
>> Correct?
>
> Almost. @name is the property name (e.g. "policy"), not the type name.
> But @type becomes redundant with qapi_type->name when qapi_type is set
> (object_property_add_qapi derive prop->type from qapi_type->name).
>
> Also @type carries additional information for some property kinds that
> @qapi_type doesn't cover: child and link embed the linked
> object's QOM type name in the type string. qapi_type can't represent
> that atm.
Can child and link properties have non-null @qapi_type?
>> Would "every ObjectProperty has a QAPI type" be a reasonable goal for
>> the future?
>
> Maybe? we would need to address the child<>/link<> gap. At least we
> can make raw object_property_add() deprecated/static in object.c after
> this series
Interesting!
>> > - 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.
>>
>> Peeking at the code, I find:
>>
>> * The type
>>
>> typedef struct QAPITypeInfo {
>> const char *name;
>> const char *schema_name;
>> const QEnumLookup *lookup;
>> const struct QAPITypeInfo *list;
>> } QAPITypeInfo;
>>
>> * A T_type_info for each QAPI type T, including built-in types.
>>
>> * T_type_info member @name is T's QAPI name, i.e. "T".
>>
>> * T_type_info member @schema_name is T's masked name used in
>> query-qmp-schema output, null when T is elided there.
>>
>> * T_type_info member @list points to TList_type_info when that exists,
>> else it's null.
>>
>> * T_type_info member @lookup points to T_lookup when T is an enum, else
>> it's null.
>>
>> Correct?
>
> Yes
>
>> > - 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.
>>
>> To be precise: when ObjectPropertyInfo member @type is "T", then member
>> @qapi-type is T_type_info.qapi-type. Correct?
>
> @qapi-type is T_type_info.schema_name, the masked name
Right.
>> If .qapi-type is non-null, you can use it to look up precise type
>> information via QAPI introspection, i.e. query-qmp-schema.
>>
>> Correct?
>
> Yes
>
>>
>> Possible problem: query-qmp-schema covers only types that are actually
>> used in QMP. But the above technique additionally wants QOM property
>> types. I haven't checked what your series does about this, if anything.
>
> Most types used as QOM properties are also used by QMP commands. But
> it's true that types not used by QMP get schame_name = NULL atm.
So the problem is real, and to reap the full benefit of your work, we
need to solve it. Not necessarily right away.
> Should we have a new pragma? Even if we have conditions, we may end up
> with unused types in the build, but that shouldn't be a big issue. Or
> we would need a more complicated several step build.
No need not worry about the how right now.
>> ObjectPropertyInfo is only used with QMP command handlers. It is
>> computed from ObjectProperty.
>>
>> > - Conversion of all PropertyInfo definitions from the old
>> > .type/.enum_table strings to the new .qapi_type pointer.
>>
>> The above is QOM, this is qdev.
>>
>> Like ObjectProperty, PropertyInfo gains a member @qapi_type pointing to
>> its QAPITypeInfo. Howver, this one cannot be null.
>>
>> PropertyInfo members @type and @enum_table are dropped, because they are
>> redundant with qapi_type.type and .lookup.
>>
>> Correct?
>
> Almost. Every PropertyInfo has a non-NULL qapi_type, except the array
> ones (created with DEFINE_PROP_ARRAY_INFO) which leave .qapi_type NULL
> and derive it at registration time from
> .element_info->qapi_type->list.
Can you point me to the code setting it? Would save me the digging.
> Either way, the resulting
> ObjectProperty always ends up with a non-NULL qapi_type.
>
> PropertyInfo members @type and @enum_table are dropped, because they
> are redundant with qapi_type->name and ->lookup.
Yes.
>> > - Replacement of the generic qdev_prop_array with typed per-element
>> > array PropertyInfos, removing the arrayinfo/arrayfieldsize
>> > indirection from struct Property.
>>
>>
Re: [PATCH 00/54] qom/qdev: associate properties with QAPI schema types
Hi
On Wed, Jul 29, 2026 at 2:04 PM Marc-André Lureau
wrote:
>
> Hi
>
> On Wed, Jul 29, 2026 at 11:29 AM Markus Armbruster via qemu
> development wrote:
> > > 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.
> >
> > Examples?
> >
>
> Properties using str_type_info that carry structured values with their
> own validation: macaddr ("52:54:00:12:34:56"), PCI addresses
> ("04:00.0"), netdev names, chardev names, drive names, UUID strings. A
> QAPI "typedef" (or newtype) for e.g. MacAddr, PciDevAddr, UUID could
> let tools know these aren't arbitrary strings (see "hw/nvdimm: convert
> UUID property to QAPI-aware registration" patch).
On a related note, qapi-type for integers are all collapsed to "int"
(and list of). Even though json wire accepts "int", it would be nice
to retain the original type information.
Re: [PATCH 00/54] qom/qdev: associate properties with QAPI schema types
Hi
On Wed, Jul 29, 2026 at 11:29 AM Markus Armbruster via qemu
development wrote:
> Before I dive into individual patches, let me try to work out what the
> series does as a whole.
>
> > This series adds:
> > - A new QAPITypeInfo struct that pairs a property with its QAPI schema
> > type name, enum lookup table, and list-element type.
>
> Peeking at the code, I see that ObjectProperty gains a member @qapi_type
> pointing to its QAPITypeInfo.
>
> It is null when the ObjectProperty doesn't have a QAPI type.
>
> If it's non-null, then ObjectProperty members @name and @type are
> redundant with qapi_type.name and .type.
>
> Correct?
Almost. @name is the property name (e.g. "policy"), not the type name.
But @type becomes redundant with qapi_type->name when qapi_type is set
(object_property_add_qapi derive prop->type from qapi_type->name).
Also @type carries additional information for some property kinds that
@qapi_type doesn't cover: child and link embed the linked
object's QOM type name in the type string. qapi_type can't represent
that atm.
> Would "every ObjectProperty has a QAPI type" be a reasonable goal for
> the future?
Maybe? we would need to address the child<>/link<> gap. At least we
can make raw object_property_add() deprecated/static in object.c after
this series
>
> >
> > - 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.
>
> Peeking at the code, I find:
>
> * The type
>
> typedef struct QAPITypeInfo {
> const char *name;
> const char *schema_name;
> const QEnumLookup *lookup;
> const struct QAPITypeInfo *list;
> } QAPITypeInfo;
>
> * A T_type_info for each QAPI type T, including built-in types.
>
> * T_type_info member @name is T's QAPI name, i.e. "T".
>
> * T_type_info member @schema_name is T's masked name used in
> query-qmp-schema output, null when T is elided there.
>
> * T_type_info member @list points to TList_type_info when that exists,
> else it's null.
>
> * T_type_info member @lookup points to T_lookup when T is an enum, else
> it's null.
>
> Correct?
Yes
> > - 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.
>
> To be precise: when ObjectPropertyInfo member @type is "T", then member
> @qapi-type is T_type_info.qapi-type. Correct?
@qapi-type is T_type_info.schema_name, the masked name
> If .qapi-type is non-null, you can use it to look up precise type
> information via QAPI introspection, i.e. query-qmp-schema.
>
> Correct?
Yes
>
> Possible problem: query-qmp-schema covers only types that are actually
> used in QMP. But the above technique additionally wants QOM property
> types. I haven't checked what your series does about this, if anything.
Most types used as QOM properties are also used by QMP commands. But
it's true that types not used by QMP get schame_name = NULL atm.
Should we have a new pragma? Even if we have conditions, we may end up
with unused types in the build, but that shouldn't be a big issue. Or
we would need a more complicated several step build.
> ObjectPropertyInfo is only used with QMP command handlers. It is
> computed from ObjectProperty.
>
> > - Conversion of all PropertyInfo definitions from the old
> > .type/.enum_table strings to the new .qapi_type pointer.
>
> The above is QOM, this is qdev.
>
> Like ObjectProperty, PropertyInfo gains a member @qapi_type pointing to
> its QAPITypeInfo. Howver, this one cannot be null.
>
> PropertyInfo members @type and @enum_table are dropped, because they are
> redundant with qapi_type.type and .lookup.
>
> Correct?
Almost. Every PropertyInfo has a non-NULL qapi_type, except the array
ones (created with DEFINE_PROP_ARRAY_INFO) which leave .qapi_type NULL
and derive it at registration time from
.element_info->qapi_type->list. Either way, the resulting
ObjectProperty always ends up with a non-NULL qapi_type.
PropertyInfo members @type and @enum_table are dropped, because they
are redundant with qapi_type->name and ->lookup.
> > - Replacement of the generic qdev_prop_array with typed per-element
> > array PropertyInfos, removing the arrayinfo/arrayfieldsize
> > indirection from struct Property.
>
> Before the series, an array-valued Property's @info member is
> @qdev_prop_array. @qdev_prop_array provides no information on the array
> elements. Instead, Property member @arrayinfo points to the
> PropertyInfo for the elements, and @arrayfieldsize is the size of an
> element.
>
> Your series makes PropertyInfo array-capable: new members @element_info
> and @element_size are the elements' PropertyInfo and size. It then adds
> a proper PropertyInfo for each such property, and drops
> @qdev_prop_array.
>
> Correct?
Re: [PATCH 00/54] qom/qdev: associate properties with QAPI schema types
I started writing this reply right when I saw the series, i.e. an
embarrassingly long time ago. Then stuff happened, some of it good,
some bad, this review got crowded out, and my memory purged.
I sincerely apologize for the massive delay.
Naturally, this needs a rebase now. But let me try to review it as is.
Marc-André Lureau writes:
> 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.
Sounds lovely!
> 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.
Correct.
Before I dive into individual patches, let me try to work out what the
series does as a whole.
> This series adds:
> - A new QAPITypeInfo struct that pairs a property with its QAPI schema
> type name, enum lookup table, and list-element type.
Peeking at the code, I see that ObjectProperty gains a member @qapi_type
pointing to its QAPITypeInfo.
It is null when the ObjectProperty doesn't have a QAPI type.
If it's non-null, then ObjectProperty members @name and @type are
redundant with qapi_type.name and .type.
Correct?
Would "every ObjectProperty has a QAPI type" be a reasonable goal for
the future?
>
> - 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.
Peeking at the code, I find:
* The type
typedef struct QAPITypeInfo {
const char *name;
const char *schema_name;
const QEnumLookup *lookup;
const struct QAPITypeInfo *list;
} QAPITypeInfo;
* A T_type_info for each QAPI type T, including built-in types.
* T_type_info member @name is T's QAPI name, i.e. "T".
* T_type_info member @schema_name is T's masked name used in
query-qmp-schema output, null when T is elided there.
* T_type_info member @list points to TList_type_info when that exists,
else it's null.
* T_type_info member @lookup points to T_lookup when T is an enum, else
it's null.
Correct?
> - 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.
To be precise: when ObjectPropertyInfo member @type is "T", then member
@qapi-type is T_type_info.qapi-type. Correct?
If .qapi-type is non-null, you can use it to look up precise type
information via QAPI introspection, i.e. query-qmp-schema.
Correct?
Possible problem: query-qmp-schema covers only types that are actually
used in QMP. But the above technique additionally wants QOM property
types. I haven't checked what your series does about this, if anything.
ObjectPropertyInfo is only used with QMP command handlers. It is
computed from ObjectProperty.
> - Conversion of all PropertyInfo definitions from the old
> .type/.enum_table strings to the new .qapi_type pointer.
The above is QOM, this is qdev.
Like ObjectProperty, PropertyInfo gains a member @qapi_type pointing to
its QAPITypeInfo. Howver, this one cannot be null.
PropertyInfo members @type and @enum_table are dropped, because they are
redundant with qapi_type.type and .lookup.
Correct?
> - Replacement of the generic qdev_prop_array with typed per-element
> array PropertyInfos, removing the arrayinfo/arrayfieldsize
> indirection from struct Property.
Before the series, an array-valued Property's @info member is
@qdev_prop_array. @qdev_prop_array provides no information on the array
elements. Instead, Property member @arrayinfo points to the
PropertyInfo for the elements, and @arrayfieldsize is the size of an
element.
Your series makes PropertyInfo array-capable: new members @element_info
and @element_size are the elements' PropertyInfo and size. It then adds
a proper PropertyInfo for each such property, and drops
@qdev_prop_array.
Correct?
This could perhaps be spun out and merged separately to reduce the size
of future respins.
Not mentioned:
- New QOM property creation functions for creating properties of
QAPI type. These take a QAPITypeInfo.
- Convert some properties to use them.
> - 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.
Examples?
> Comments welcome!
>
> Signed-off-by: Marc-André
[PATCH 00/54] qom/qdev: associate properties with QAPI schema types
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!
Signed-off-by: Marc-André Lureau
---
Marc-André Lureau (54):
qapi: add QAPITypeInfo struct definition
qapi/introspect: expose the type name map
qapi: add type-infos generator
qapi/backend: wire up type-infos generation
qapi/gen: fix _module_basename for multi-dash 'what' parameters
meson: add qapi-type-infos-*.c/h to build
qom: add qapi_type field to ObjectProperty
qapi/qom: add qapi-type field to ObjectPropertyInfo
qom/qmp: populate qapi-type in QMP handlers
qom: add QAPI-aware property registration
tests: update check-qom-proplist for QAPI-aware property registration
qom: convert enum properties to QAPI-aware registration
qom: remove old enum property registration API
qom: convert struct properties to QAPI-aware registration
qom: convert struct properties to QAPI-aware registration
x86: convert OnOffAuto properties to QAPI-aware registration
microvm: convert OnOffAuto properties to QAPI-aware registration
pc: convert OnOffAuto vmport property to QAPI-aware registration
arm/virt: convert OnOffAuto acpi property to QAPI-aware registration
riscv/virt: convert OnOffAuto properties to QAPI-aware registration
loongarch/virt: convert OnOffAuto properties to QAPI-aware registration
hostmem-file: convert OnOffAuto rom property to QAPI-aware registration
sev: convert OnOffAuto legacy-vm-type property to QAPI-aware registration
whpx: convert OnOffAuto hyperv property to QAPI-aware registration
whpx: convert OnOffAuto arch properties to QAPI-aware registration
accel/kvm: convert OnOffSplit property to QAPI-aware registration
whpx: convert OnOffSplit property to QAPI-aware registration
ppc/spapr-caps: convert to QAPI-aware property registration
system/memory: fix "priority" property typename
hw/mem/nvdimm: fix "size" property typename
qom: convert scalar properties to QAPI-aware registration
i386/cpu: convert strList property to QAPI-aware registration
accel/hvf: convert OnOffSplit property to QAPI-aware registration
i386/x86: convert SgxEPCList property to QAPI-aware registration
virtio-balloon: convert guest-stats property to QAPI type
qom: replace object_property_add_tm with StructTm QAPI type
hw/nvdimm: convert UUID property to QAPI-aware registration
hw/s390-virtio-ccw: convert loadparm property to QAPI-aware registration
hw/ppc/spapr_drc: convert fdt property to QAPI-aware registration
spdm-socket: convert SpdmTransportType to QAPI enum
hw/pci: change the busnr type to uint8
qdev: add qapi_type field to PropertyInfo with fallback registration
qdev: convert core PropertyInfo definitions to use qapi_type
qdev: convert system PropertyInfo definitions to use qapi_type
hw: convert device-local PropertyInfo definitions to use qapi_type
target/riscv: fix incorrect QAPI types and u8 casting
target/riscv: convert PropertyInfo definitions to use qapi_type
qdev: convert PropertyInfo definitions to use qapi_type
qdev: introduce typed array PropertyInfos
qdev: simplify DEFINE_PROP_ARRAY
