Daniel P. Berrangé <berra...@redhat.com> writes: > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote: >> Christophe de Dinechin <dinec...@redhat.com> writes: >> >> > Thanks a bunch. This clarifies a number of my misconceptions about >> > how this is currently used. Most notably this one: >> > >> >> On 15 Jan 2020, at 10:20, Markus Armbruster <arm...@redhat.com> wrote: >> >> >> >>> We don’t want the QAPI to let arbitrary fields of a QOM object >> >>> be modified, do we? >> >> >> >> We already do: QMP command qom-set. If it breaks your guest, you get to >> >> keep the pieces. >> > >> > Ouch. I certainly did not expect that. >> > >> > "It is not what you don’t know that kills you, it is what you know that >> > ain’t so". >> >> Do we have a legitimate use for qom-set right now? Hmm, let's check >> libvirt... aha: >> >> * qemuMonitorJSONSetMemoryStatsPeriod() uses it to control >> virtio-balloon's guest-stats-polling-interval property, in accordance >> with docs/virtio-balloon-stats.txt. >> >> * qemuMonitorJSONSetIOThread() uses it to control iothread's properties >> poll-max-ns, poll-grow, poll-shrink. Their use with -object is >> documented (in qemu-options.hx), their use with qom-set is not. >> >> Oh well. > > Libvirt is of course happy to switch to something else instead of > qom-set for these features if QEMU wants to provide a safer > alternative.
Noted. libvirt's use of qom-set is okay. What's not okay is the near-complete lack of QOM documentation, its poor QMP interface, in part due to non-integration with QAPI, and last but not least the lack of QOM leadership leaving it adrift.
