On Wed, May 24, 2017 at 02:13:16PM +0200, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > 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. > > Okay. > > >> > 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. > > Given the direct parents, computing their transitive closure is trivial. > So a single query should suffice.
If you have the full list, yes. I was thinking of something like asking "does type FOO is a (direct or indirect) child of BAR?". "qom-list-types implements=FOO" wouldn't suffice. "qom-list-types implements=BAR" would be enough, but it would also return all subtypes of BAR. However, I think this example is not very realistic. libvirt, for example, does query everything about QEMU capabilities only once, and then cache it. Even if a client doesn't cache it, the size of "qom-list-types implements=BAR" should be reasonable. > > > 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. > > Perhaps libvirt developers can help us here. The only usage of qom-list-types I found in libvirt has no command arguments, and is called by code that checks for cached information first. > > > I believe the size will stay > > acceptable if we implement the two suggestions above. > > Please do. -- Eduardo