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

["Kővágó Zoltán" <dirty.ice.hu@gmail.com>]

2015-07-02 19:34 keltezéssel, Markus Armbruster írta:
> "Kővágó, Zoltán" <dirty.ice.hu@gmail.com> 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 <DirtY.iCE.hu@gmail.com>
>>
>> ---
>>
>> 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?

The reason why this whole flattening stuff is done it's because 
otherwise this nested parsing patch breaks backward compatibility.

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

I'm afraid that only the audio patches contains code that actually use 
this new feature.  But that has a lot of configuration options that 
apply to both input and output, and having a shared struct that is 
available via `in.' and `out.' is better than having to manually 
duplicate all these settings under unique names in a single struct (like 
in_frequency, out_frequency, in_channels, out_channels, ...).