qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [PATCH v3 1/4] qapi: net: Add query-netdevs command
Date: Wed, 16 Sep 2020 13:28:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Alexey Kirillov <lekiravi@yandex-team.ru> writes:

> 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?

Depends on how we answer my 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.

If we need it to be precise, you have to define a suitable enum.

Else, you may define such an enum, or reuse NetClientDriver.

If no clear answer emerges, the decision devolves to the maintainer in
charge (Jason, I think).

In my opinion, defining a suitable enum is the more prudent choice.

It partially duplicates NetClientDriver.  No big deal for the schema, as
you already duplicate most of Netdev.  Possibly awkward in C, but to
know for sure, we'd have to try.

> If that is, I will continue using NetClientDriver as a discriminator.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]