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