On Tue, May 23, 2017 at 04:12:43PM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > This series adds 'abstract' and 'parent-types' fields to the > > output of qom-list-types. > > Peeking at PATCH 3, it looks like 'parent-types' is the transitive > closure of the single direct parent type (TypeImpl member parent_type). > Do we need information on interfaces as well?
I think we should, but it is more complex so I plan to do in a separate patch. > > > For reference, below are the sizes of the output of > > "qom-list-types abstract=true" on qemu-system-x86_64, before and > > after applying the patches: > > > > * before: 11724 bytes > > * with 'abstract' field: 20119 bytes > > * with 'abstract' and 'parent-types': 44383 bytes > > Obvious ways to save space: > > * Make 'abstract' optional, default to false, present only when > necessary (79 out of 456 times right now) Good idea. > > * Pare down 'parent-types' to *direct* parent types. The indirect ones > are redundant. On the one hand, I assume clients don't care if a given type is a direct parent or indirect parent, and including only the direct parent type will require them to make extra queries. On the other hand, if the client wants to save a few queries it can use the "implements" argument, already? Not sure. > > A less obvious way: > > * 'parent-types' defines a relation with adjacency lists. If the > relation is tree-shaped, we can send the tree instead, i.e. a tree of > device names rather than list of (device name, adjacency list). New > command unless we're willing to break qom-list-types. > > > I'm not sure if extending qom-list-types with this info is the > > right way to go, or if we should keep qom-list-types as-is and > > add a new "query-qom-type" QMP command to query info on one QOM > > type at a time. > > Might lead to more traffic rather than less. Depends on what > information the client needs to query. I think queries that return all available QOM types are likely to (should?) be cached by clients. I believe the size will stay acceptable if we implement the two suggestions above. -- Eduardo