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. >>>> http://dreamsongs.com/RiseOfWorseIsBetter.html >>> >>> You know that I positively hate this ;-) >> >> It's been a tough lesson for me, too. > > Not sure I can call it a “lesson”. Much like a philosophy to fight against, > IMO. The tough lesson isn't philosophy, it's an observation: "I believe that worse-is-better [...] has better survival characteristics than the-right-thing". >>> Well, I guess we can expand the schema. #ILoveJSON. >> >> Basing the QAPI language on JSON was a poor choice. Not sure that's >> fixable at a reasonable cost. > > Well, at least now I have a slightly better understanding of the related costs > and trade-offs. Thanks a lot for explaining. You're welcome!
