From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
qemu-devel@nongnu.org, "Amit Shah" <amit@kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
dgilbert@redhat.com, "Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>,
"Artyom Tarasenko" <atar4qemu@gmail.com>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 05/10] qom/globals: generalize object_property_set_globals()
Date: Thu, 1 Nov 2018 11:18:42 +0100 [thread overview]
Message-ID: <20181101111842.4d93b7c7@redhat.com> (raw)
In-Reply-To: <20181031201256.GA30771@habkost.net>
On Wed, 31 Oct 2018 17:12:56 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Tue, Oct 30, 2018 at 07:04:48PM +0400, Marc-André Lureau wrote:
> > Handle calls of object_property_set_globals() with any object type,
> > but only apply globals to TYPE_DEVICE & TYPE_USER_CREATABLE.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> > qom/globals.c | 22 ++++++++++++++--------
> > 1 file changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/qom/globals.c b/qom/globals.c
> > index 587f4a1b5c..8664baebe0 100644
> > --- a/qom/globals.c
> > +++ b/qom/globals.c
> > @@ -15,22 +15,28 @@ void object_property_register_global(GlobalProperty *prop)
> >
> > void object_property_set_globals(Object *obj)
> > {
> > - DeviceState *dev = DEVICE(obj);
> > GList *l;
> > + DeviceState *dev = (DeviceState *)object_dynamic_cast(obj, TYPE_DEVICE);
> > +
> > + if (!dev && !IS_USER_CREATABLE(obj)) {
> > + /* only TYPE_DEVICE and TYPE_USER_CREATABLE support globals */
> > + return;
> > + }
>
> This is core QOM code, ideally type-specific code doesn't belong
> here.
>
> This also duplicates the purpose of the ObjectClass::set_globals
> flag you have added on another patch, doesn't it? I suggest just
> dropping this hunk, and letting callers decide if it's
> appropriate to call object_property_set_globals() or not.
>
> >
> > for (l = global_props; l; l = l->next) {
> > GlobalProperty *prop = l->data;
> > Error *err = NULL;
> >
> > - if (object_dynamic_cast(OBJECT(dev), prop->driver) == NULL) {
> > + if (object_dynamic_cast(obj, prop->driver) == NULL) {
> > continue;
> > }
> > prop->used = true;
> > - object_property_parse(OBJECT(dev), prop->value, prop->property, &err);
> > + object_property_parse(obj, prop->value, prop->property, &err);
> > if (err != NULL) {
> > error_prepend(&err, "can't apply global %s.%s=%s: ",
> > prop->driver, prop->property, prop->value);
> > - if (!dev->hotplugged && prop->errp) {
> > +
> > + if (dev && !dev->hotplugged && prop->errp) {
>
> Hmm, more type-specific code. Can't we get rid of the
> dev->hotplugged check here?
>
> Maybe changing the function signature to:
> void object_property_set_globals(Object *obj, bool propagate_errors);
> and let the caller decide?
>
> Or we could try to find a way to get rid of prop->errp. I never
> really liked that hack, anyway.
>
> Anyway, I won't mind keeping this code as-is if the solution is
> too complex.
>
>
> > error_propagate(prop->errp, err);
> > } else {
> > assert(prop->user_provided);
> > @@ -56,15 +62,15 @@ int object_property_check_globals(void)
> > continue;
> > }
> > oc = object_class_by_name(prop->driver);
> > - oc = object_class_dynamic_cast(oc, TYPE_DEVICE);
> > - if (!oc) {
> > + dc = (DeviceClass *)object_class_dynamic_cast(oc, TYPE_DEVICE);
> > + if (!IS_USER_CREATABLE_CLASS(oc) && !dc) {
>
> This could use the ObjectClass::set_globals flag you have added.
>
> > warn_report("global %s.%s has invalid class name",
> > prop->driver, prop->property);
> > ret = 1;
> > continue;
> > }
> > - dc = DEVICE_CLASS(oc);
> > - if (!dc->hotpluggable && !prop->used) {
> > +
> > + if (dc && !dc->hotpluggable) {
>
> I wonder how we could get rid of this type-specific check. Maybe
> a ObjectClass::only_init_time_globals flag, automatically
> initialized by TYPE_DEVICE based on DeviceClass::hotpluggable?
in v1, I've suggested to add a hook something like
ObjectClass::set_globals(Object *obj)
that will handle type specific code and probably
drop instance_post_init() hook.
that would be better than adding boolean ObjectClass::set_globals
as it could serve as both a flag and a type specific handler.
So in the end we would end up replacing instance_post_init()
with set_globals() hook.
> In this case, I'm not sure it would be worth the extra
> complexity. The type-specific code is just for a warning,
> anyway, so it's not a big deal.
>
>
> > warn_report("global %s.%s=%s not used",
> > prop->driver, prop->property, prop->value);
> > ret = 1;
> > --
> > 2.19.0.271.gfe8321ec05
> >
> >
>
next prev parent reply other threads:[~2018-11-01 10:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-30 15:04 [Qemu-devel] [PATCH v2 00/10] hostmem: use object "id" for memory region name with >= 3.1 Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 01/10] qom: make user_creatable_complete() specific to UserCreatable Marc-André Lureau
2018-11-01 11:03 ` Igor Mammedov
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 02/10] accel: register global_props like machine globals Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 03/10] qdev: move qdev_prop_register_global_list() to tests Marc-André Lureau
2018-10-31 20:22 ` Eduardo Habkost
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 04/10] qom/globals: move qdev globals to qom Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 05/10] qom/globals: generalize object_property_set_globals() Marc-André Lureau
2018-10-31 20:12 ` Eduardo Habkost
2018-11-01 10:18 ` Igor Mammedov [this message]
2018-11-01 15:27 ` Eduardo Habkost
2018-11-01 15:58 ` Igor Mammedov
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 06/10] qom/object: set globals when initializing object Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 07/10] qom/object: add set_globals flags Marc-André Lureau
2018-10-31 20:23 ` Eduardo Habkost
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 08/10] tests: add user-creatable test to test-qdev-global-props Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 09/10] hw/i386: add pc-i440fx-3.1 & pc-q35-3.1 Marc-André Lureau
2018-10-31 20:14 ` Eduardo Habkost
2018-11-01 14:59 ` Igor Mammedov
2018-11-20 12:00 ` Marc-André Lureau
2018-10-30 15:04 ` [Qemu-devel] [PATCH v2 10/10] hostmem: use object id for memory region name with >= 3.1 Marc-André Lureau
2018-10-31 20:27 ` Eduardo Habkost
2018-11-01 15:16 ` Igor Mammedov
2018-11-01 15:31 ` Eduardo Habkost
2018-10-31 14:41 ` [Qemu-devel] [PATCH v2 00/10] hostmem: use object "id" " no-reply
2018-10-31 14:43 ` no-reply
2018-11-03 3:37 ` no-reply
2018-11-03 3:39 ` no-reply
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=20181101111842.4d93b7c7@redhat.com \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=amit@kernel.org \
--cc=atar4qemu@gmail.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).