qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Igor Mammedov" <imammedo@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: QMP introspecting device props common to a bus type
Date: Fri, 9 Apr 2021 08:46:42 +0200	[thread overview]
Message-ID: <20210409064642.ah2tz5vjz2ngfiyo@sirius.home.kraxel.org> (raw)
In-Reply-To: <87o8eo9609.fsf@dusky.pond.sub.org>

  Hi,

> device-list-properties uses module_object_class_by_name(), requires the
> result to be a concrete device type, iterates over QOM properties with
> object_property_iter_init() / object_property_iter_next(), skipping
> properties named "type", "realized", "hotpluggable", "hotplugged",
> "parent_bus", and any whose starts with "legacy-".
> 
> Paolo, can you remind us why we skip the "legacy-FOO" properties?
> 
> qom-list-properties uses object_class_by_name(), requires an object type
> (an interface won't do).  If it's abstract, it iterates with
> object_class_property_iter_init() / object_property_iter_next(), else
> with object_property_iter_init() / object_property_iter_next().  It
> doesn't skip properties.
> 
> Looks like device-list-properties has become[*] pretty much redundant
> *except* for the difference between module_object_class_by_name() and
> object_class_by_name().
> 
> Gerd, you changed device-list-properties from object_class_by_name() to
> module_object_class_by_name() in commit 7ab6e7fcce.  Should
> qom-list-properties be changed, too?

Makes sense.  We already have non-device modular objects
(some chardevs).

> If yes, is there any reason to use
> object_class_by_name() for looking up user-provided type names in QMP
> commands?

I've tried to be conservative and call module_object_class_by_name()
only in places where it is actually needed.  Reason one being the extra
overhead.  But maybe this isn't too bad given the extra module code runs
only on lookup failures.  Reason two is to avoid modules being loaded by
accident even when not needed.  This needs checking when you try drop
object_class_by_name().  A VM without --for example -- qxl device should
not load the qxl module.

take care,
  Gerd



  reply	other threads:[~2021-04-09  6:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 13:44 QMP introspecting device props common to a bus type Daniel P. Berrangé
2021-04-08 11:56 ` Markus Armbruster
2021-04-08 12:46   ` Daniel P. Berrangé
2021-04-08 14:59     ` Markus Armbruster
2021-04-09  6:46       ` Gerd Hoffmann [this message]
2021-04-09  9:18         ` Markus Armbruster
2021-04-09  9:41           ` Daniel P. Berrangé
2021-04-09 14:04             ` Markus Armbruster

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=20210409064642.ah2tz5vjz2ngfiyo@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=imammedo@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).