From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: pbonzini@redhat.com, berrange@redhat.com, qemu-devel@nongnu.org,
eblake@redhat.com, ehabkost@redhat.com
Subject: Re: [RFC PATCH 02/12] qom: Create object_configure()
Date: Tue, 14 Dec 2021 10:52:56 +0100 [thread overview]
Message-ID: <YbhpeGHYRX8ZNUBd@redhat.com> (raw)
In-Reply-To: <8735nm6gkw.fsf@dusky.pond.sub.org>
Am 23.11.2021 um 16:23 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
>
> > This renames object_set_properties_from_qdict() to object_configure()
> > and removes the QDict parameter from it: With visit_next_struct_member()
> > it can set all properties without looking at the keys of the QDict.
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> > qom/object_interfaces.c | 13 ++++++-------
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c
> > index 3b61c195c5..f9f5608194 100644
> > --- a/qom/object_interfaces.c
> > +++ b/qom/object_interfaces.c
> > @@ -42,16 +42,15 @@ bool user_creatable_can_be_deleted(UserCreatable *uc)
> > }
> > }
> >
> > -static void object_set_properties_from_qdict(Object *obj, const QDict *qdict,
> > - Visitor *v, Error **errp)
> > +static void object_configure(Object *obj, Visitor *v, Error **errp)
> > {
> > - const QDictEntry *e;
> > + const char *key;
> >
> > if (!visit_start_struct(v, NULL, NULL, 0, errp)) {
> > return;
> > }
> > - for (e = qdict_first(qdict); e; e = qdict_next(qdict, e)) {
> > - if (!object_property_set(obj, e->key, v, errp)) {
> > + while ((key = visit_next_struct_member(v))) {
> > + if (!object_property_set(obj, key, v, errp)) {
> > goto out;
> > }
> > }
> > @@ -69,7 +68,7 @@ void object_set_properties_from_keyval(Object *obj, const QDict *qdict,
> > } else {
> > v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
> > }
> > - object_set_properties_from_qdict(obj, qdict, v, errp);
> > + object_configure(obj, v, errp);
> > visit_free(v);
> > }
> >
> > @@ -108,7 +107,7 @@ Object *user_creatable_add_type(const char *type, const char *id,
> >
> > assert(qdict);
>
> This is the only remaining use of parameter @qdict. Let's drop it.
Indeed, very good. I've never liked this interface that needs a QDict in
addition to the visitor.
> > obj = object_new(type);
> > - object_set_properties_from_qdict(obj, qdict, v, &local_err);
> > + object_configure(obj, v, &local_err);
> > if (local_err) {
> > goto out;
> > }
>
> Brief recap how configuration data flows trough QMP object-add to QOM:
>
> * QMP object-add is fully typed: union ObjectOptions. QMP core parses
> input via QDict to ObjectOptions (JSON parser + QObject input
> visitor), and passes that to qmp_object_add().
>
> * qmp_object_add() passes it on to user_creatable_add_qapi().
>
> Aside: getting rid of the wrapper would be as easy as renaming
> user_creatable_add_qapi() to qmp_object_add().
>
> * user_creatable_add_qapi() converts right back to QDict (QObject output
> visitor). It extracts the non-properties "qom-type" and "id", and
> passes the properties (wrapped in a QObject input visitor) to
> user_creatable_add_type().
>
> * user_creatable_add_type() feeds the properties to object_configure(),
> formerly object_set_properties_from_qdict().
>
> Your patch simplifies one detail of the last step. Small
> simplifications are welcome, too.
>
> The visitor ping-pong remains: input -> output -> input.
>
> We play visitor ping-pong because we reduce the problem "for each member
> of ObjectOptions: set property" to the solved problem "set properties
> for an input visitor".
>
> Straight solution of the problem: a QOM property output visitor.
I'm not sure how that should work? You can't drive a visit from both
sides and QOM properties already take an input visitor. The only way I
see to make this work is converting to QObjects and creating input
visitors internally in the QOM property output visitor, which would kind
of defeat the purpose.
What could in theory be done is passing a Visitor to qmp_object_add()
instead of ObjectOptions (in the long run, we probably don't want a big
union of all existing QOM types anyway). But if directly pass this on to
QOM, we lose all of the QAPI validation, which we don't want either.
Kevin
next prev parent reply other threads:[~2021-12-14 9:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 17:29 [RFC PATCH 00/12] QOM/QAPI integration part 1 Kevin Wolf
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 [this message]
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=YbhpeGHYRX8ZNUBd@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).