Stefan Hajnoczi <stefa...@gmail.com> writes: > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote: >> Christophe de Dinechin <dinec...@redhat.com> writes: >> >> On 15 Jan 2020, at 10:20, Markus Armbruster <arm...@redhat.com> 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.