Re: Making QEMU easier for management tools and applications

[Marc-André Lureau]

Hi

On Tue, Jan 21, 2020 at 3:32 PM Stefan Hajnoczi <address@hidden> wrote:
>
> On Tue, Jan 21, 2020 at 06:42:47AM +0100, Markus Armbruster wrote:
> > Stefan Hajnoczi <address@hidden> writes:
> >
> > > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
> > >> Christophe de Dinechin <address@hidden> writes:
> > >> >> On 15 Jan 2020, at 10:20, Markus Armbruster <address@hidden> 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.
>
> Thoughts about a solution:
>
> Static QOM properties should be declared via QAPI instead of
> imperatively via QOM APIs.  That way they are introspectable and type
> information is present in the schema.
>
> The QAPI code generator could emit a function that is callable from
> .class_init().  This eliminates the need to manually call
> object_class_property_add().

I have this in mind too. First step is probably to move as much as
possible as class properties. Please review
https://patchew.org/QEMU/address@hidden/,
I have more of this kind of qdev/qom cleanups pending.



-- 
Marc-André Lureau