Re: [Libguestfs] [PATCH RFC 1/5] qapi: Enable enum member introspection to show more than name
Peter Krempa <pkrempa(a)redhat.com> writes:
On Wed, Sep 15, 2021 at 21:24:21 +0200, Markus Armbruster wrote:
> The next commit will add feature flags to enum members. There's a
> problem, though: query-qmp-schema shows an enum type's members as an
> array of member names (SchemaInfoEnum member @values). If it showed
> an array of objects with a name member, we could simply add more
> members to these objects. Since it's just strings, we can't.
>
> I can see three ways to correct this design mistake:
>
> 1. Do it the way we should have done it, plus compatibility goo.
>
> We want a ['SchemaInfoEnumMember'] member in SchemaInfoEnum. Since
> changing @values would be a compatibility break, add a new member
> @members instead.
>
> @values is now redundant. We should be able to get rid of it
> eventually.
>
> In my testing, output of qemu-system-x86_64's query-qmp-schema
> grows by 11% (18.5KiB).
I prefer this one. While the schema output grows, nobody is really
reading it manually.
True, but growing schema output can only slow down client startup.
Negligible for libvirt, I presume?
The implementation in libvirt is very straightforward:
https://gitlab.com/pipo.sk/libvirt/-/commit/24f1709cfae72cd765d02dc2124d6...
https://gitlab.com/pipo.sk/libvirt/-/commit/5909db9d4994327b3f64d5c329edd...
> 2. Like 1, but omit "boring" elements of @member, and empty @member.
>
> @values does not become redundant. Output of query-qmp-schema
> grows only as we make enum members non-boring.
This has 2 drawbacks:
- we would never get rid of either of those
- clients would have to check both, one for whether the member is
present and second whether it's non-boring.
IMO it's simpler for clients just to prefer the new approach when
present as the old is simply a subset.
Noted.
> 3. Versioned query-qmp-schema.
>
> query-qmp-schema provides either @values or @members. The QMP
> client can select which version it wants.
At least for libvirt this poses a chicken & egg problem. We'd have to
query the schema to see that it has the switch to do the selection and
then probe with the modern one.
The simplest solution is to try the versions the management application
can understand in order of preference (newest to oldest) until one
succeeds. I'd expect the first try to work most of the time. Only when
you combine new libvirt with old QEMU, the fallback has to kick in.
Other parts of the management application should remain oblivous of the
differences.
We could of course try to reduce the number of roundtrips, say by
putting sufficient information into the QMP greeting (one roundtrip), or
the output of query-qmp-schema (try oldest to find the best one, then
try the best one unless it's the oldest). I doubt that's worthwhile.
I'm not trying to talk you into this solution. We're just exploring the
solution space together, and with an open mind.