From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Denis V. Lunev" <den@virtuozzo.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Christophe de Dinechin" <dinechin@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"John Snow" <jsnow@redhat.com>,
"Dominik Csapak" <d.csapak@proxmox.com>
Subject: Re: Integrating QOM into QAPI
Date: Tue, 21 Jan 2020 19:11:35 +0400 [thread overview]
Message-ID: <CAJ+F1CJ68_QM7zhqoL-bom3vFSNprN3zOV5FUBtrJWg4nAai5g@mail.gmail.com> (raw)
In-Reply-To: <871rrs97ld.fsf@dusky.pond.sub.org>
Hi
On Tue, Jan 21, 2020 at 7:01 PM Markus Armbruster <armbru@redhat.com> wrote:
>
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Tue, Jan 21, 2020 at 02:36:17PM +0100, Markus Armbruster wrote:
> >> Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> >>
> >> > Hi
> >> >
> >> > On Tue, Jan 21, 2020 at 3:32 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >> >>
> >> >> On Tue, Jan 21, 2020 at 06:42:47AM +0100, Markus Armbruster wrote:
> >> >> > Stefan Hajnoczi <stefanha@gmail.com> writes:
> >> >> >
> >> >> > > On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
> >> >> > >> Christophe de Dinechin <dinechin@redhat.com> writes:
> >> >> > >> >> On 15 Jan 2020, at 10:20, Markus Armbruster <armbru@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.
> >> >>
> >> >> 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().
> >>
> >> We need to make up our minds what exactly we want generated. Then we
> >> can design the QAPI language, and code up the generator.
> >>
> >> Skeleton QOM type, to help with the discussion:
> >>
> >> #define TYPE_FOO "foo"
> >>
> >> #define FOO(obj) OBJECT_CHECK(Foo, (obj), TYPE_FOO)
> >> #define FOO_CLASS(klass) \
> >> OBJECT_CLASS_CHECK(FooClass, (klass), TYPE_FOO)
> >> #define FOO_GET_CLASS(obj) \
> >> OBJECT_GET_CLASS(FooClass, (obj), TYPE_FOO)
> >>
> >> typedef FooClass {
> >> ParentClass parent_class;
> >> ... // hand-written per-class state
> >> }
> >>
> >> struct Chardev {
> >> ParentObject parent_obj;
> >> ... // hand-written instance (per-object) state
> >> };
> >>
> >> static const TypeInfo char_type_info = {
> >> .name = TYPE_FOO,
> >> .parent = TYPE_OBJECT,
> >> .instance_size = sizeof(Foo),
> >> .instance_init = ..., // methods to initialize
> >> .instance_post_init = ..., // and finalize instances,
> >> .instance_finalize = ..., // all optional
> >> .abstract = ..., // true or false (d'oh)
> >> .class_size = sizeof(FooClass),
> >> .class_init = ..., // methods to initialize
> >> .class_base_init = ..., // classes, optional
> >> .class_data = ..., // extra argument for them
> >> .interfaces = ...
> >> };
> >>
> >> There's substantial boilerplate, with plenty of hand-written code in the
> >> gaps. What of the boilerplate do we plan to generate? How do we plan
> >> to fill the gaps, if any?
> >
> > FWIW, even without a QOM generator, we can do waaaaaaay better on the
> > amount of boilerplate needed for QOM without very much work. It just
> > needs a few convenience macros writing.
> >
> > QOM is not GObject, but is heavily inspired by it and so looking at
> > GObject gives us a design pattern we can aim to match in terms of
> > amount of boilerplate.
> >
> > What we do manually with TypeInfo struct there has essentially always
> > been done by a 1 line macro in GObject:
> >
> > G_DEFINE_TYPE(virIdentity, vir_identity, G_TYPE_OBJECT)
> >
> > If implementing interfaces, there's 1 extra line needed per interface
> > to associate them.
> >
> > https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DEFINE-TYPE:CAPS
> >
> >
> > And what we do in the header file to add the 4 or more FOO_XXX macros,
> > and the class struct and the object struct has recently been turned
> > into a 2-liner:
> >
> > #define VIR_TYPE_IDENTITY vir_identity_get_type()
> > G_DECLARE_FINAL_TYPE(virIdentity, vir_identity, VIR, IDENTITY, GObject);
> >
> > https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DECLARE-FINAL-TYPE:CAPS
> >
> > Or
> >
> > #define VIR_TYPE_IDENTITY vir_identity_get_type()
> > G_DECLARE_DERIVABLE_TYPE(virIdentity, vir_identity, VIR, IDENTITY, GObject);
> >
> > https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DECLARE-DERIVABLE-TYPE:CAPS
> >
> >
> > It would be nice to have a QOM code generator so that we can statically
> > declare properties & parent/child/interface relationships, but for an
> > immediate low cost win, better macros would be very useful IMHO.
>
> Volunteers?
>
Actually, we are not that far off from being able to use GObject
altogether (I hacked something like that to play with), but I
disgress...
So introducing GObject-like macros? sure!
There are plenty of refactoring to do. The problem when touching the
whole code-base, imho, is review time. It may take a couple of
hours/days to come up with a cocci/spatch, and make various patches
here and there. But it takes often weeks and a lot of constant push to
various folks to get all the reviews (as seens by the qdev prop-ptr
series earlier for example). How can we better address whole code-base
changes?
--
Marc-André Lureau
next prev parent reply other threads:[~2020-01-21 15:12 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 16:13 Making QEMU easier for management tools and applications Stefan Hajnoczi
2019-12-20 21:07 ` Richard W.M. Jones
2020-01-02 11:26 ` Stefan Hajnoczi
2019-12-21 9:02 ` Markus Armbruster
2019-12-23 15:04 ` Michal Prívozník
2020-01-07 9:36 ` Kevin Wolf
2020-01-07 10:55 ` Michal Privoznik
2020-01-07 12:57 ` Kevin Wolf
2020-01-07 17:53 ` Christophe de Dinechin
2019-12-24 13:41 ` Daniel P. Berrangé
2020-01-22 22:28 ` John Snow
2020-01-23 7:19 ` Markus Armbruster
2020-01-23 17:58 ` John Snow
2020-01-23 19:01 ` Daniel P. Berrangé
2020-01-23 21:07 ` John Snow
2020-01-24 7:59 ` Markus Armbruster
2020-01-24 10:27 ` Daniel P. Berrangé
2020-01-24 14:38 ` Kevin Wolf
2020-01-24 18:23 ` John Snow
2020-01-24 18:30 ` Dr. David Alan Gilbert
2020-01-24 18:48 ` John Snow
2020-01-24 18:52 ` Dr. David Alan Gilbert
2020-01-24 18:58 ` John Snow
2020-01-25 10:18 ` Markus Armbruster
2020-01-27 10:18 ` Daniel P. Berrangé
2020-01-27 12:48 ` Markus Armbruster
2020-01-27 11:56 ` Kevin Wolf
2020-01-27 12:04 ` Peter Maydell
2020-01-27 20:11 ` John Snow
2020-01-27 22:38 ` Paolo Bonzini
2020-01-28 0:37 ` John Snow
2020-01-28 10:16 ` Daniel P. Berrangé
2020-01-28 10:39 ` Kevin Wolf
2020-01-28 15:36 ` Markus Armbruster
2020-01-31 12:25 ` Eric Blake
2020-01-28 10:28 ` Kevin Wolf
2020-01-28 12:36 ` Markus Armbruster
2020-01-28 12:54 ` Kevin Wolf
2020-01-28 13:45 ` Gerd Hoffmann
2020-01-31 6:50 ` Markus Armbruster
2020-01-31 7:48 ` Paolo Bonzini
2020-01-31 8:09 ` Markus Armbruster
2020-02-03 20:07 ` Andrea Bolognani
2020-02-04 9:58 ` Markus Armbruster
2020-01-31 12:27 ` Eric Blake
2020-02-02 9:21 ` Kevin Wolf
2020-02-02 10:44 ` Paolo Bonzini
2020-02-03 6:20 ` Markus Armbruster
2020-02-03 8:48 ` Markus Armbruster
2020-01-27 20:12 ` Dr. David Alan Gilbert
2020-01-24 20:34 ` John Snow
2020-01-27 8:35 ` Gerd Hoffmann
2020-01-27 12:13 ` Kevin Wolf
2020-01-27 16:18 ` Gerd Hoffmann
2020-01-24 9:50 ` Daniel P. Berrangé
2020-01-25 11:52 ` Paolo Bonzini
2020-01-27 10:05 ` Daniel P. Berrangé
2020-01-27 8:25 ` Tooling to help humans use JSON (was: Making QEMU easier for management tools and applications) Markus Armbruster
2020-01-27 9:06 ` Making QEMU easier for management tools and applications Markus Armbruster
2020-01-27 10:00 ` Daniel P. Berrangé
2020-01-27 14:35 ` Kevin Wolf
2020-01-27 20:29 ` Dr. David Alan Gilbert
2020-01-28 10:59 ` Kevin Wolf
2020-02-05 13:09 ` Kevin Wolf
2020-02-05 19:09 ` qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications) John Snow
2020-02-05 19:49 ` Dr. David Alan Gilbert
2020-02-06 9:40 ` qmp-shell for GSoC/Outreachy? Markus Armbruster
2020-02-06 10:09 ` Daniel P. Berrangé
2020-02-06 12:11 ` Markus Armbruster
2020-02-06 12:15 ` Daniel P. Berrangé
2020-02-06 18:02 ` Dr. David Alan Gilbert
2020-02-07 21:03 ` John Snow
2020-02-08 7:17 ` Markus Armbruster
2020-02-06 14:21 ` Kevin Wolf
2020-02-06 18:26 ` Dr. David Alan Gilbert
2020-02-07 10:49 ` Kevin Wolf
2020-02-07 21:23 ` John Snow
2020-02-08 7:25 ` Markus Armbruster
2020-02-10 11:59 ` Kevin Wolf
2020-02-10 12:26 ` Kevin Wolf
2020-02-06 18:18 ` Dr. David Alan Gilbert
2020-02-07 7:47 ` Markus Armbruster
2020-02-07 21:31 ` Eric Blake
2020-02-08 7:34 ` Markus Armbruster
2020-02-07 21:56 ` John Snow
2020-02-07 20:56 ` John Snow
2020-01-27 20:59 ` Making QEMU easier for management tools and applications John Snow
2020-01-28 10:16 ` Markus Armbruster
2020-01-28 19:21 ` John Snow
2020-01-24 6:38 ` Markus Armbruster
2020-01-25 22:34 ` Christophe de Dinechin
2020-01-25 11:55 ` Paolo Bonzini
2020-01-02 14:47 ` Stefan Hajnoczi
2020-01-16 11:03 ` Kashyap Chamarthy
2020-01-20 9:55 ` Stefan Hajnoczi
2020-01-20 13:57 ` Kashyap Chamarthy
2020-01-25 11:41 ` Paolo Bonzini
2020-01-27 19:41 ` John Snow
2020-01-02 15:05 ` Dr. David Alan Gilbert
2020-01-13 13:44 ` Markus Armbruster
2019-12-24 13:00 ` Daniel P. Berrangé
2020-01-02 14:22 ` Stefan Hajnoczi
2020-01-22 22:42 ` John Snow
2020-01-23 7:21 ` Markus Armbruster
2020-01-23 10:27 ` Daniel P. Berrangé
2020-01-23 18:13 ` John Snow
2020-01-23 19:12 ` Daniel P. Berrangé
2020-01-02 15:10 ` Dr. David Alan Gilbert
2020-01-07 17:11 ` Christophe de Dinechin
2020-01-08 10:43 ` Kevin Wolf
2020-01-08 11:40 ` Christophe de Dinechin
2020-01-08 13:38 ` Kevin Wolf
2020-01-14 13:04 ` Markus Armbruster
2020-01-14 17:31 ` Christophe de Dinechin
2020-01-15 9:20 ` Markus Armbruster
2020-01-15 9:34 ` Christophe de Dinechin
2020-01-15 12:15 ` Markus Armbruster
2020-01-15 12:19 ` Daniel P. Berrangé
2020-01-15 14:02 ` Markus Armbruster
2020-01-30 21:09 ` Improving QOM documentation [Was: Re: Making QEMU easier for management tools and applications] Kashyap Chamarthy
2020-01-31 6:11 ` Markus Armbruster
2020-01-31 7:46 ` Paolo Bonzini
2020-01-31 15:37 ` Christophe de Dinechin
2020-01-31 16:28 ` Paolo Bonzini
2020-01-31 9:50 ` Kashyap Chamarthy
2020-01-31 10:35 ` Peter Maydell
2020-01-31 11:02 ` Paolo Bonzini
2020-01-31 15:22 ` Kashyap Chamarthy
2020-01-31 17:23 ` Markus Armbruster
2020-02-03 8:56 ` Paolo Bonzini
2020-02-03 9:54 ` Markus Armbruster
2020-02-03 15:21 ` Paolo Bonzini
2020-02-04 8:42 ` Markus Armbruster
2020-01-31 16:39 ` Markus Armbruster
2020-01-20 10:08 ` Making QEMU easier for management tools and applications Stefan Hajnoczi
2020-01-21 5:42 ` Markus Armbruster
2020-01-21 11:32 ` Stefan Hajnoczi
2020-01-21 12:03 ` Marc-André Lureau
2020-01-21 13:36 ` Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications) Markus Armbruster
2020-01-21 14:36 ` Daniel P. Berrangé
2020-01-21 15:01 ` Integrating QOM into QAPI Markus Armbruster
2020-01-21 15:11 ` Marc-André Lureau [this message]
2020-01-21 16:21 ` Peter Maydell
2020-01-22 5:16 ` Getting whole-tree patches reviewed and merged (was: Integrating QOM into QAPI) Markus Armbruster
2020-02-07 21:53 ` Getting whole-tree patches reviewed and merged Eric Blake
2020-02-10 11:26 ` Paolo Bonzini
2020-02-10 16:04 ` Markus Armbruster
2020-02-10 16:12 ` Peter Maydell
2020-01-22 10:50 ` Integrating QOM into QAPI Alex Bennée
2020-01-22 12:24 ` Markus Armbruster
2020-01-22 12:42 ` Marc-André Lureau
2020-01-22 13:28 ` Peter Maydell
2020-01-22 13:32 ` Marc-André Lureau
2020-01-23 7:37 ` Markus Armbruster
2020-01-24 18:32 ` Paolo Bonzini
2020-01-25 4:44 ` Marc-André Lureau
2020-01-25 9:28 ` Paolo Bonzini
2020-01-25 21:25 ` Peter Maydell
2020-01-26 8:09 ` Christophe de Dinechin
2020-01-26 9:11 ` Marc-André Lureau
2020-01-26 16:47 ` Paolo Bonzini
2020-01-27 19:05 ` Christophe de Dinechin
2020-01-27 19:05 ` Christophe de Dinechin
2020-01-26 15:04 ` Peter Maydell
2020-01-27 19:05 ` Christophe de Dinechin
2020-01-28 8:00 ` Markus Armbruster
2020-01-28 10:03 ` Daniel P. Berrangé
2020-01-29 12:42 ` Christophe de Dinechin
2020-01-15 9:35 ` Making QEMU easier for management tools and applications Marc-André Lureau
2020-01-15 12:25 ` Markus Armbruster
2020-01-25 17:18 ` Paolo Bonzini
2020-01-27 9:30 ` Markus Armbruster
2020-01-13 16:30 ` Stefan Hajnoczi
2020-02-04 15:54 ` Summary of " Markus Armbruster
2020-02-05 6:38 ` Markus Armbruster
2020-02-10 10:56 ` Stefan Hajnoczi
2020-02-10 11:01 ` Peter Maydell
2020-02-10 11:08 ` Daniel P. Berrangé
2020-02-10 11:29 ` Peter Maydell
2020-02-10 11:04 ` Paolo Bonzini
2020-02-10 16:43 ` Markus Armbruster
2020-02-12 13:54 ` Stefan Hajnoczi
2020-02-12 14:03 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ+F1CJ68_QM7zhqoL-bom3vFSNprN3zOV5FUBtrJWg4nAai5g@mail.gmail.com \
--to=marcandre.lureau@gmail.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=d.csapak@proxmox.com \
--cc=den@virtuozzo.com \
--cc=dinechin@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).