[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making QEMU easier for management tools and applications

From: Markus Armbruster
Subject: Re: Making QEMU easier for management tools and applications
Date: Wed, 15 Jan 2020 13:15:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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

>>> 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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]