qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, berrange@redhat.com, ehabkost@redhat.com,
	armbru@redhat.com, pbonzini@redhat.com, eblake@redhat.com
Subject: [RFC PATCH 00/12] QOM/QAPI integration part 1
Date: Wed,  3 Nov 2021 18:29:50 +0100	[thread overview]
Message-ID: <20211103173002.209906-1-kwolf@redhat.com> (raw)

This series adds QOM class definitions to the QAPI schema, introduces
a new TypeInfo.instance_config() callback that configures the object at
creation time (instead of setting properties individually) and is
separate from runtime property setters (which often used to be not
really tested for runtime use), and finally generates a marshalling
function for .instance_config() from the QAPI schema that makes this a
natural C interface rather than a visitor based one.

This is loosely based on Paolo's old proposal in the wiki:
https://wiki.qemu.org/Features/QOM-QAPI_integration

The series is in a rather early stage and I don't really have any
automated tests or documentation in this series yet. I'm also only
converting the class hierarchy for the random number generator backends
to show what the result looks like, the other objects still need to be
done.

So the question to you isn't whether this is mergeable (it isn't), but
whether you think this is the right approach for starting to integrate
QOM and QAPI better.

You'll also see that this doesn't really remove the duplication between
property definitions in the code and configuration struct definitions in
the QAPI schema yet (because we want to keep at least a read-only
runtime property for every configuration option), but at least they mean
somewhat different things now (creation vs. runtime) instead of being
completely redundant.

Possible future steps:

* Define at least those properties to the schema that correspond to a
  config option. For both setters and getters for each option, we'll
  probably want to select in the schema between 'not available',
  'automatically generated function' and 'manually implemented'.

  Other runtime properties could be either left in the code or added to
  the schema as well. Either way, we need to figure out how to best
  describe these things in the schema.

* Getting rid of the big 'object-add' union: While the union is not too
  bad for the rather small number of user-creatable objects, it
  wouldn't scale at all for devices.

  My idea there is that we could define something like this:

  { 'struct': 'ObjectOptions',
    'data': {
        'id': 'str',
        'config': { 'type': 'qom-config-any:user-creatable',
                    'embed': true } } }

  Obviously this would be an extension of the schema language to add an
  'embed' option (another hopefully more acceptable attempt to flatten
  things...), so I'd like to hear opinions on this first before I go to
  implement it.

  Also note that 'qom-config-any:user-creatable' is new, too. The
  'qom-config:...' types introduced by this series don't work for
  subclasses, but only for the exact class.

  On the external interface, the new 'qom-config-any:...' type including
  subclasses would basically behave (and be introspected) like the union
  we have today, just without being defined explicitly.

  As for the C representation for configurations that include
  subclasses, I'm imagining a struct that just contains the qom_type
  string (so we can call the right handler) and a pointer to the real
  config (that is treated as opaque by the generic code).

I could probably add more, but let's just start with this for discussion
now.

Kevin Wolf (12):
  qapi: Add visit_next_struct_member()
  qom: Create object_configure()
  qom: Make object_configure() public
  qom: Add instance_config() to TypeInfo
  rng-random: Implement .instance_config
  rng-backend: Implement .instance_config
  qapi: Allow defining QOM classes
  qapi: Create qom-config:... type for classes
  qapi/qom: Convert rng-backend/random to class
  qapi: Generate QOM config marshalling code
  qapi/qom: Add class definition for rng-builtin
  qapi/qom: Add class definition for rng-egd

 qapi/qom.json                |  46 ++++++++++-----
 include/qapi/visitor-impl.h  |   3 +
 include/qapi/visitor.h       |   2 +
 include/qom/object.h         |   7 +++
 backends/rng-egd.c           |  18 +++---
 backends/rng-random.c        |  18 +++---
 backends/rng.c               |  22 ++++++--
 qapi/qapi-visit-core.c       |   6 ++
 qapi/qobject-input-visitor.c |  16 ++++++
 qom/object.c                 |  32 +++++++++++
 qom/object_interfaces.c      |  22 +-------
 scripts/qapi/expr.py         |  28 ++++++++-
 scripts/qapi/main.py         |   2 +
 scripts/qapi/qom.py          |  91 ++++++++++++++++++++++++++++++
 scripts/qapi/schema.py       | 106 +++++++++++++++++++++++++++++++++++
 qapi/meson.build             |   3 +
 qapi/trace-events            |   1 +
 17 files changed, 362 insertions(+), 61 deletions(-)
 create mode 100644 scripts/qapi/qom.py

-- 
2.31.1



             reply	other threads:[~2021-11-03 17:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 17:29 Kevin Wolf [this message]
2021-11-03 17:29 ` [RFC PATCH 01/12] qapi: Add visit_next_struct_member() Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 02/12] qom: Create object_configure() Kevin Wolf
2021-11-23 15:23   ` Markus Armbruster
2021-12-14  9:52     ` Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 03/12] qom: Make object_configure() public Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 04/12] qom: Add instance_config() to TypeInfo Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 05/12] rng-random: Implement .instance_config Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 06/12] rng-backend: " Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 07/12] qapi: Allow defining QOM classes Kevin Wolf
2021-11-23 10:02   ` Markus Armbruster
2021-12-10 17:53     ` Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 08/12] qapi: Create qom-config:... type for classes Kevin Wolf
2021-11-23 13:00   ` Markus Armbruster
2021-12-10 17:41     ` Kevin Wolf
2021-11-03 17:29 ` [RFC PATCH 09/12] qapi/qom: Convert rng-backend/random to class Kevin Wolf
2021-11-23 13:15   ` Markus Armbruster
2021-12-10 17:57     ` Kevin Wolf
2021-11-03 17:30 ` [RFC PATCH 10/12] qapi: Generate QOM config marshalling code Kevin Wolf
2021-11-23 14:16   ` Markus Armbruster
2021-12-10 16:50     ` Kevin Wolf
2021-11-03 17:30 ` [RFC PATCH 11/12] qapi/qom: Add class definition for rng-builtin Kevin Wolf
2021-11-03 17:30 ` [RFC PATCH 12/12] qapi/qom: Add class definition for rng-egd Kevin Wolf
2021-11-03 21:26 ` [RFC PATCH 00/12] QOM/QAPI integration part 1 Paolo Bonzini
2021-11-04  9:07   ` Kevin Wolf
2021-11-04 12:39     ` Paolo Bonzini
2021-11-04 14:26       ` Kevin Wolf
2021-11-04 14:49         ` Paolo Bonzini
2021-11-04 15:51           ` Kevin Wolf
2021-11-04 15:52     ` Damien Hedde
2021-11-05 13:55       ` Kevin Wolf
2021-11-23 16:05 ` Markus Armbruster
2021-12-14 10:23   ` Kevin Wolf
2021-12-14 10:40     ` Peter Maydell
2021-12-14 11:52       ` Kevin Wolf
2021-12-14 14:45     ` Markus Armbruster
2021-12-14 16:00       ` Kevin Wolf

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=20211103173002.209906-1-kwolf@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).