Re: [Qemu-devel] [RFC] qmp: Return 'user_creatable' & 'hotpluggable' fields on qom-list-types

[Markus Armbruster]

Eduardo Habkost <address@hidden> writes:

> Currently there's no way for QMP clients to get a list of device types
> that are really usable with -device.  This information would be useful
> for management software and test scripts (like the device-crash-test
> script I have submitted recently).  Interestingly, the "info qdm" HMP
> command provides this information, but no QMP command does.
>
> Add two new fields to the return value of qom-list-types:
> "user-creatable-device" and "hotpluggable-device".

Does the combination

    "user-creatable-device": false,
    "hotpluggable-device": true

make any sense?

Exposing information on user-creatable/hot-pluggable via QMP makes
sense.  The question is how.  This is a design question, and as so often
with design questions, I need more words to make my case than I'd like
to.  Please bear with me.

>                                                     Also, add extra
> arguments for filtering the list of types based on the new fields.

I consider the case for filtering weak.  Let's ignore this part for now.

We have a number of commands to introspect static information,
e.g. query-version, query-commands, query-qmp-schema, query-target,
query-machines, query-cpu-definitions, query-chardev-backends,
device-list-properties, qom-list-types.

Aside: us abandoning the convention to name such commands query-FOO is
regrettable.

In its basic form, i.e. without arguments, qom-list-types does what its
name suggests: it lists the QOM types.

It also permits finding out whether a type is abstract, but only in a
roundabout way: subtract the result of running it without arguments (or
with 'abstract':false) from the result with 'abstract':true.

It also permits finding the "implements" relation, but only in an even
more roundabout way: run it with 'implements':T for every abstract T,
then solve the resulting puzzle.

Unless there's a direct way to find both (and I'm not aware of any),
this is bad design.  The obvious fix is to extend its return type to
include the information.

With qom-list-types fixed that way, there's precedence for exposing
additional information on QOM types there.

Note that both the "abstract" bit and the "implements directly" list
apply to any QOM type, not just to certain subtypes.  As proposed,
"user-creatable-device' and "hotpluggable-device" apply only to the
"device" subtype.  There's no precedence for exposing information
specific to certain subtypes.

If we want to do it anyway, then qom-list-type should perhaps return a
union.  Taken to the logical conclusion, this becomes a nest of unions
mirroring the "direct subtype of" relation.  Hmm.

However, we already have a command to introspect device types:
device-list-properties.  Can we expose the information as read-only
property/ies of type "device" and be done?

But perhaps they aren't really specific to devices.  There are other QOM
types that can be created by users, e.g. with -object, so the
"user-creatable" bit applies more widely.  Are any of them only
creatable during initial startup?  If yes, then that applies more
widely, too.

> I'm not sure about the naming of the new command arguments.  Maybe the
> names are too long, but I believe that "user-creatable-devices-only=false"
> would have more obvious semantics than "user-creatable-devices=false"
> (the latter looks ambiguous: it could mean "return only
> non-user-creatable devices" or "return all devices").

I consider the filtering feature unnecessary complexity.  The filtering
we have got in against my objections.  I won't veto additional filtering
outright, but I will insist on test coverage.

The unfiltered output of qom-list-types is less than 10 KiB.  Even if we
extend it some, the need to filter it client-side seems dubious.  If a
management application really wants to save resources here, it should
cache the result and re-get it only when QEMU changes.