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