Re: [Qemu-devel] [PATCH 4/5] qapi: support nested structs in OptsVisitor

[Markus Armbruster]

"Kővágó, Zoltán" <address@hidden> writes:

> The current OptsVisitor flattens the whole structure, if there are same
> named fields under different paths the current visitor can't cope with
> them (it'll just set the first field, leaving the others unspecified (if
> they're optional) or erroring out (if they're required).
>
> This patch add support for it, by always requiring a complete path in
> case of nested structs.  Fields in the path are separated by dots,
> similar to C structs (without pointers), like `foo.bar'.
>
> You must provide a full path even in non-ambigous cases.  The previous
> two commits hopefully ensures that this change doesn't create backward
> compatibility problems.
>
> Signed-off-by: Kővágó, Zoltán <address@hidden>
>
> ---
>
> Rationale for this commit: see these threads
> http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg04189.html
> http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg04186.html

So, despite your flattening work, we still need to parse option strings
into nested QAPI types?

Can you give examples of the need for such nested QAPI types in
configuration?  I may have seen them already in your audio patches, but
I think having some right here would be useful.