From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z586w-0006gG-33 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 03:50:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z586s-0007kz-QR for qemu-devel@nongnu.org; Wed, 17 Jun 2015 03:50:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56618) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z586s-0007kr-9j for qemu-devel@nongnu.org; Wed, 17 Jun 2015 03:50:10 -0400 From: Markus Armbruster References: <88a1cc0775d3d4f5262b31b9452f8acccc6bbb41.1434458391.git.DirtY.iCE.hu@gmail.com> Date: Wed, 17 Jun 2015 09:50:07 +0200 In-Reply-To: <88a1cc0775d3d4f5262b31b9452f8acccc6bbb41.1434458391.git.DirtY.iCE.hu@gmail.com> (=?utf-8?B?IkvFkXbDoWfDsywgWm9sdMOhbiIncw==?= message of "Tue, 16 Jun 2015 14:49:05 +0200") Message-ID: <87oakeg4eo.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: =?utf-8?B?S8WRdsOhZ8OzLCBab2x0w6Fu?= Cc: =?utf-8?B?TMOhc3psw7M=?= Ersek , Gerd Hoffmann , qemu-devel@nongnu.org, Michael Roth Copying L=C3=A1szl=C3=B3 because his fingerprints are on OptsVisitor. "K=C5=91v=C3=A1g=C3=B3, Zolt=C3=A1n" writes: > The current OptsVisitor flattens the whole structure, if there are same n= amed > fields under different paths (like `in' and `out' in `Audiodev'), the cur= rent > visitor can't cope with them (for example setting `frequency=3D44100' wil= l 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 the > specified name (this means it would set both in's and out's frequency = to > 44100 in the above example). > 2) Optionally user can specify the path in the hierarchy. Names are separ= ated by > a dot (e.g. `in.frequency', `foo.bar.something', etc). The user need n= ot > specify the whole path, only the last few components (i.e. `bar.someth= ing' is > equivalent to `foo.bar.something' if only `foo' has a `bar' field). Th= is way > 1) is just a special case of this when only the last component is spec= ified. > 3) In case of an ambiguity (e.g `frequency=3D44100,in.frequency=3D8000') = the longest > matching (the most specific) path wins (so in this example, in's frequ= ency > would become 8000, because `in.frequency' is more specific that `frequ= ency', > and out's frequency would become 44100, because only `frequency' match= es it). Can you explain why the complexity is needed, i.e. why we can't just require full paths always?