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: Tue, 08 Sep 2020 16:31:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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.




reply via email to

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