Marc-André Lureau <marcandre.lur...@redhat.com> writes:
> Use the actual unsigned integer type name (this should't break since
> property type aren't directly accessed from outside it seems).
I checked. Uses of Object member @type outside qom/object.c:
* vl.c's machine_help_func() puts it in help for -machine NAME,help.
Fine.
* QMP command qom-list exposes it in ObjectPropertyInfo member @type.
Your commit message is wrong :)
* QMP command device-list-properties exposes it in DevicePropertyInfo
member @type.
* spapr_drc_populate_dt() compares it to "link<", which may or may not
be a good idea, but isn't affected by your patch.
Uses in qom/object.c:
* object_property_is_child() compares it to "child<". Not affected by
your patch.
* object_property_get_enum() takes it as argument. Shouldn't be
affected by your patch, as only enumeration type names should occur
here. Double-checking: I can see "HostMemPolicy", "DummyAnimal",
"BadAnimal" (the latter two in tests/, don't worry). Okay.
* object_property_get_type() returns it.
- qdev_print_props() only checks whether it succeeds. Not affected by
your patch.
- object_resolve_link() requires it to be of the form "link<%s>". Not
affected by your patch unless we violate this precondition (and then
we have worse problems).
* object_property_add_alias() copies it, possibly rewriting "child<%s>"
to "link<%s>". Shouldn't be affected by your patch.
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Rewrite the commit message to explain impact on -machine, qom-list and
device-list-properties, and you may add
Reviewed-by: Markus Armbruster <arm...@redhat.com>
