From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z58us-0006u9-5f for qemu-devel@nongnu.org; Wed, 17 Jun 2015 04:41:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z58uo-0002BT-49 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 04:41:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z58un-00029p-V7 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 04:41:46 -0400 Message-ID: <1434530501.5549.23.camel@redhat.com> From: Gerd Hoffmann Date: Wed, 17 Jun 2015 10:41:41 +0200 In-Reply-To: <87oakeg4eo.fsf@blackfin.pond.sub.org> References: <88a1cc0775d3d4f5262b31b9452f8acccc6bbb41.1434458391.git.DirtY.iCE.hu@gmail.com> <87oakeg4eo.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Michael Roth , =?ISO-8859-1?Q?L=E1szl=F3?= Ersek , qemu-devel@nongnu.org, =?UTF-8?Q?K=C5=91v=C3=A1g=C3=B3=2C_Zolt=C3=A1n?= On Mi, 2015-06-17 at 09:50 +0200, Markus Armbruster wrote: > Copying L=C3=A1szl=C3=B3 because his fingerprints are on OptsVisitor. >=20 > "K=C5=91v=C3=A1g=C3=B3, Zolt=C3=A1n" writes: >=20 > > The current OptsVisitor flattens the whole structure, if there are sa= me named > > fields under different paths (like `in' and `out' in `Audiodev'), the= current > > visitor can't cope with them (for example setting `frequency=3D44100'= will set the > > in's frequency to 44100 and leave out's frequency unspecified). > > > > This patch fixes it, by the following changes: > > 1) Specifying just the field name will apply to all fields that has t= he > > specified name (this means it would set both in's and out's freque= ncy to > > 44100 in the above example). > > 2) Optionally user can specify the path in the hierarchy. Names are s= eparated by > > a dot (e.g. `in.frequency', `foo.bar.something', etc). The user ne= ed not > > specify the whole path, only the last few components (i.e. `bar.so= mething' is > > equivalent to `foo.bar.something' if only `foo' has a `bar' field)= . This way > > 1) is just a special case of this when only the last component is = specified. > > 3) In case of an ambiguity (e.g `frequency=3D44100,in.frequency=3D800= 0') the longest > > matching (the most specific) path wins (so in this example, in's f= requency > > would become 8000, because `in.frequency' is more specific that `f= requency', > > and out's frequency would become 44100, because only `frequency' m= atches it). >=20 > Can you explain why the complexity is needed, i.e. why we can't just > require full paths always? Keeping the short names is required for -netdev backward compatibility. Restricting to short or full (i.e. something=3D or foo.bar.something=3D, = but disallow bar.something=3D) should not be a problem. I'm not sure this simplifies things much though. We have to build the full path anyway, and I think bar.something=3D is just a convenient thing we get almost for free ... cheers, Gerd