From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAyrn-0002Gp-OU for qemu-devel@nongnu.org; Fri, 03 Jul 2015 07:10:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAyrf-0007bF-Qp for qemu-devel@nongnu.org; Fri, 03 Jul 2015 07:10:47 -0400 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:34262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAyrf-0007aj-AP for qemu-devel@nongnu.org; Fri, 03 Jul 2015 07:10:39 -0400 Received: by wiar9 with SMTP id r9so127863909wia.1 for ; Fri, 03 Jul 2015 04:10:37 -0700 (PDT) From: "=?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?=" References: <2839919cc06b59a7db292c7bae87b4660cc07376.1435064848.git.DirtY.iCE.hu@gmail.com> <87k2uiqx8k.fsf@blackfin.pond.sub.org> Message-ID: <55966DBC.40702@gmail.com> Date: Fri, 3 Jul 2015 13:10:52 +0200 MIME-Version: 1.0 In-Reply-To: <87k2uiqx8k.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 4/5] qapi: support nested structs in OptsVisitor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , Michael Roth 2015-07-02 19:34 keltezéssel, Markus Armbruster írta: > "Kővágó, Zoltán" 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 >> >> --- >> >> 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, ...).