[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC PATCH 00/12] QOM/QAPI integration part 1
From: |
Kevin Wolf |
Subject: |
[RFC PATCH 00/12] QOM/QAPI integration part 1 |
Date: |
Wed, 3 Nov 2021 18:29:50 +0100 |
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
- [RFC PATCH 00/12] QOM/QAPI integration part 1,
Kevin Wolf <=
- [RFC PATCH 02/12] qom: Create object_configure(), Kevin Wolf, 2021/11/03
- [RFC PATCH 01/12] qapi: Add visit_next_struct_member(), Kevin Wolf, 2021/11/03
- [RFC PATCH 03/12] qom: Make object_configure() public, Kevin Wolf, 2021/11/03
- [RFC PATCH 04/12] qom: Add instance_config() to TypeInfo, Kevin Wolf, 2021/11/03
- [RFC PATCH 05/12] rng-random: Implement .instance_config, Kevin Wolf, 2021/11/03
- [RFC PATCH 06/12] rng-backend: Implement .instance_config, Kevin Wolf, 2021/11/03
- [RFC PATCH 07/12] qapi: Allow defining QOM classes, Kevin Wolf, 2021/11/03
- [RFC PATCH 08/12] qapi: Create qom-config:... type for classes, Kevin Wolf, 2021/11/03