Stefan Hajnoczi <[email protected]> writes:
> On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
>> Christophe de Dinechin <[email protected]> writes:
>> >> On 15 Jan 2020, at 10:20, Markus Armbruster <[email protected]> wrote:
>> * 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.
>
> I'm happy to use a different interface.
>
> Writing a boilerplate "iothread-set-poll-params" QMP command in C would
> be a step backwards.
No argument.
> Maybe the QAPI code generator could map something like this:
>
> { 'command': 'iothread-set-poll-params',
> 'data': {
> 'id': 'str',
> '*max-ns': 'uint64',
> '*grow': 'uint64',
> '*shrink': 'uint64'
> },
> 'map-to-qom-set': 'IOThread'
> }
>
> And turn it into QOM accessors on the IOThread object.
I think a generic "set this configuration to that value" command is just
fine. qom-set fails on several counts, though:
* Tolerable: qom-set is not actually generic, it applies only to QOM.
* qom-set lets you set tons of stuff that is not meant to be changed at
run time. If it breaks your guest, you get to keep the pieces.
* There is virtually no documentation on what can be set to what values,
and their semantics.
In its current state, QOM is a user interface superfund site.
