Eduardo Habkost <ehabk...@redhat.com> 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.