From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5BMh-0006kM-Gq for qemu-devel@nongnu.org; Wed, 17 Jun 2015 07:18:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5BMb-00007q-BO for qemu-devel@nongnu.org; Wed, 17 Jun 2015 07:18:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5BMb-00007I-31 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 07:18:37 -0400 From: Markus Armbruster References: <88a1cc0775d3d4f5262b31b9452f8acccc6bbb41.1434458391.git.DirtY.iCE.hu@gmail.com> <87oakeg4eo.fsf@blackfin.pond.sub.org> <1434530501.5549.23.camel@redhat.com> Date: Wed, 17 Jun 2015 13:18:33 +0200 In-Reply-To: <1434530501.5549.23.camel@redhat.com> (Gerd Hoffmann's message of "Wed, 17 Jun 2015 10:41:41 +0200") Message-ID: <87bngea8hi.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: Gerd Hoffmann Cc: Kevin Wolf , dirty.ice.hu@gmail.com, =?utf-8?B?TMOhc3psw7M=?= Ersek , Michael Roth , qemu-devel@nongnu.org Copying Kevin because similar issues exist in the block layer. Gerd Hoffmann writes: > 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 >> > same 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 the >> > specified name (this means it would set both in's and out's frequen= cy to >> > 44100 in the above example). What if they have different types? What if one of them can't take the value? >> > 2) Optionally user can specify the path in the hierarchy. Names >> > are separated by >> > a dot (e.g. `in.frequency', `foo.bar.something', etc). The user nee= d not >> > specify the whole path, only the last few components >> > (i.e. `bar.something' 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=3D8000') the longest >> > matching (the most specific) path wins (so in this example, >> > in's frequency >> > would become 8000, because `in.frequency' is more specific that >> > frequency', >> > and out's frequency would become 44100, because only >> > frequency' matches it). The current rule for multiple assignments is "last one wins". E.g. in -drive if=3Dnone,file=3Dtmp.img,file=3Dtmp.qcow2 file=3Dtmp.qcow2 wins. If I understand correctly, this patch amends the rule to "last most specific one wins". Correct? >> 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. I suspect mostly because NetLegacy and Netdev aren't flat unions. Could be self-inflicted pain. What about flattening them instead? Assuming that's possible; I'd have to try. > 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 ... We've been bitten by convenience features before. Adding them tends to be cheap, but maintaining compatibility can become a terrible headache.