aboutsummaryrefslogtreecommitdiff
path: root/qom
diff options
context:
space:
mode:
authorAlexey Kardashevskiy <aik@ozlabs.ru>2018-05-30 17:11:29 +1000
committerPaolo Bonzini <pbonzini@redhat.com>2018-06-01 14:15:10 +0200
commit24ed11723230e43f44e9a1aef72e7c71714288d1 (patch)
tree5acdc40e77cae1db2196e6375f2ec4af0bcfa330 /qom
parentb969ea6bcddbac3c1956f5b8d0cc49dbd17f59a2 (diff)
downloadqemu-24ed11723230e43f44e9a1aef72e7c71714288d1.zip
qemu-24ed11723230e43f44e9a1aef72e7c71714288d1.tar.gz
qemu-24ed11723230e43f44e9a1aef72e7c71714288d1.tar.bz2
qom: Document qom/device-list-properties implementation specific
The recently introduced qom-list-properties QMP command raised a question what properties it (and its cousin - device-list-properties) can possibly print - only those defined by DeviceClass::props or dynamically created in TypeInfo::instance_init() so properties created elsewhere won't show up and this behaviour might confuse the user. For example, PIIX4 does that from piix4_pm_realize() via piix4_pm_add_propeties(): object_property_add_uint8_ptr(OBJECT(s), ACPI_PM_PROP_ACPI_ENABLE_CMD, &acpi_enable_cmd, NULL); This adds a note to the command descriptions about the limitation. Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20180530071129.9013-1-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'qom')
0 files changed, 0 insertions, 0 deletions