From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Db4-00052v-3o for qemu-devel@nongnu.org; Wed, 17 Jun 2015 09:41:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Day-0007If-QD for qemu-devel@nongnu.org; Wed, 17 Jun 2015 09:41:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Day-0007IZ-Lh for qemu-devel@nongnu.org; Wed, 17 Jun 2015 09:41:36 -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> <87bngea8hi.fsf@blackfin.pond.sub.org> <55816405.7090502@gmail.com> Date: Wed, 17 Jun 2015 15:41:33 +0200 In-Reply-To: <55816405.7090502@gmail.com> (=?utf-8?B?IkvFkXbDoWfDsyBab2x0?= =?utf-8?B?w6FuIidz?= message of "Wed, 17 Jun 2015 14:11:49 +0200") Message-ID: <87bnge310y.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?S8WRdsOhZ8OzIFpvbHTDoW4=?= Cc: Kevin Wolf , qemu-devel@nongnu.org, =?utf-8?B?TMOhc3psw7M=?= Ersek , Gerd Hoffmann , Michael Roth "K=C5=91v=C3=A1g=C3=B3 Zolt=C3=A1n" writes: > 2015-06-17 13:18 keltez=C3=A9ssel, Markus Armbruster =C3=ADrta: >> 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. >>>> >>>> "K=C5=91v=C3=A1g=C3=B3, Zolt=C3=A1n" writes: >>>> >>>>> 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 t= he >>>>> specified name (this means it would set both in's and out's >>>>> frequency to >>>>> 44100 in the above example). >> >> What if they have different types? >> >> What if one of them can't take the value? > > Currently it will error out, requiring the user to be more > explicit. Probably not the best solution, but I can't really think of > a better solution. (If we would ignore invalid values that would be > very confusing imho.) Yes, we clearly don't want foo=3D0 to set a.foo and b.foo, but foo=3Dx set only a.foo, because the former can take any string, but the latter only a number. Can we require the LHS to be unambiguous? [...]