|
From: | Kővágó Zoltán |
Subject: | Re: [Qemu-devel] [PATCH 4/5] qapi: support nested structs in OptsVisitor |
Date: | Fri, 3 Jul 2015 13:10:52 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 |
2015-07-02 19:34 keltezéssel, Markus Armbruster írta:
"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.htmlSo, 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, ...).
[Prev in Thread] | Current Thread | [Next in Thread] |