[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/3] qmp: Return extra information on qom-list-typ
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [RFC 0/3] qmp: Return extra information on qom-list-types |
Date: |
Wed, 24 May 2017 14:13:16 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Eduardo Habkost <address@hidden> writes:
> On Tue, May 23, 2017 at 04:12:43PM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <address@hidden> 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.
> 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.
> I believe the size will stay
> acceptable if we implement the two suggestions above.
Please do.