Re: [PATCH v3 1/4] qapi: net: Add query-netdevs command

[Alexey Kirillov]

08.09.2020, 17:32, "Markus Armbruster" <armbru@redhat.com>:
> Eric Blake <eblake@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