08.09.2020, 17:32, "Markus Armbruster" <arm...@redhat.com>: > Eric Blake <ebl...@redhat.com> writes: > >> On 9/7/20 7:39 AM, Markus Armbruster wrote: >> >>>>> This is union Netdev plus a common member @peer-id, less the variant >>>>> members for NetClientDriver values 'nic' and 'hubport'. >>>>> >>>>> Can 'type: 'nic' and 'type': 'hubport' occur? >>>> >>>> No, it can't. We don't support NIC/hubport in query-netdevs, so we >>>> neither create this >>>> structure for them, nor store config. >>> Same for 'none', I guess. >>> As defined, NetdevInfo allows types 'none', 'nic', and 'hubport', it >>> just has no variant members for them. The fact that they can't occur is >>> not coded into the type, and therefore not visible in introspection. >>> To make introspection more precise, we'd have to define a new enum >>> type. >>> How much that would complicate the C code is unclear. >>> Do we need it to be more precise? Eric, got an opinion? >> >> Is the problem that a new enum would be duplicating things? > > Enumerating network drivers twice is mildly annoying. I worry more > about having to convert between the two enumerations in C. > > My actual question: do we need query-qmp-schema report the precise set > of 'type' values? As is, it reports a few that can't actually occur. > >> Is it >> worth allowing one enum to have a 'base':'OtherEnum' in the schema to >> reduce some of the duplication? > > We could then generate functions (or macros) to convert from base enum > to extended enum, and back, where the latter can fail. > > Worthwhile only if we have sufficient use for it.
I'm sorry, did I understand correctly that at the moment I don't need any additional changes in the patch yet? If that is, I will continue using NetClientDriver as a discriminator. -- Alexey Kirillov Yandex.Cloud
