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

On Fri, Apr 09, 2021 at 11:18:42AM +0200, Markus Armbruster wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
> >   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.
> Yes, module load should be reasonably explicit, to avoid accidental
> loading.
> Automatic load on use is explicit enough.
> Automatic load on introspection could perhaps be surprising.  I figure
> it depends on how the introspection request is phrased.  Loading X on
> "tell me more about X" feels okay.  Loading X on "show me all the X that
> satisfy Y" feels iffy.

IIUC, the intention is that as designed today, the existance of modules
is supposed to be transparent to mgmt application.

IOW, to a mgmt app "qemu + installed qxl module" should behaviour
identically to "qemu + statically linked qxl".

Conversely "qemu + uninstalled qxl module" should behaviour identically
to "qemu + qxl disabled at buld time".

This implies that when a mgmt app introspects QEMU for features, then
QEMU must auto-load all modules that are needed to ensure introspection
results match those that would be reported in non-modular build.

If we not going to make introspetion results equivalent, then we may
need to make modules be an explicit concept so mgmt apps can find out
when introspection is incomplete and force loading when they need it.

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2021-04-09  9:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 13:44 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
2021-04-09  9:18         ` Markus Armbruster
2021-04-09  9:41           ` Daniel P. Berrangé [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YHAhQWdX15V54U8G@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --subject='Re: QMP introspecting device props common to a bus type' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).