Re: QMP introspecting device props common to a bus type

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

Regards,
Daniel
-- 
|: 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 :|