[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making QEMU easier for management tools and applications
From: |
Stefan Hajnoczi |
Subject: |
Re: Making QEMU easier for management tools and applications |
Date: |
Tue, 21 Jan 2020 11:32:24 +0000 |
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().
Stefan
signature.asc
Description: PGP signature
- Re: Making QEMU easier for management tools and applications, (continued)
- Re: Making QEMU easier for management tools and applications, Kevin Wolf, 2020/01/08
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/14
- Re: Making QEMU easier for management tools and applications, Christophe de Dinechin, 2020/01/14
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Christophe de Dinechin, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Daniel P . Berrangé, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/15
- Re: Making QEMU easier for management tools and applications, Stefan Hajnoczi, 2020/01/20
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/21
- Re: Making QEMU easier for management tools and applications,
Stefan Hajnoczi <=
- Re: Making QEMU easier for management tools and applications, Marc-André Lureau, 2020/01/21
- Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications), Markus Armbruster, 2020/01/21
- Re: Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications), Daniel P . Berrangé, 2020/01/21
- Re: Integrating QOM into QAPI, Markus Armbruster, 2020/01/21
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/21
- Re: Integrating QOM into QAPI, Peter Maydell, 2020/01/21
- Getting whole-tree patches reviewed and merged (was: Integrating QOM into QAPI), Markus Armbruster, 2020/01/22
- Re: Integrating QOM into QAPI, Alex Bennée, 2020/01/22
- Re: Integrating QOM into QAPI, Markus Armbruster, 2020/01/22
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/22