Re: Making QEMU easier for management tools and applications

[Markus Armbruster]

Christophe de Dinechin <address@hidden> 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 <address@hidden> 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!