From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Dwc-0007gd-4z for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:04:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5DwX-0000Fx-Cl for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:03:58 -0400 Received: from mail-wg0-x22c.google.com ([2a00:1450:400c:c00::22c]:36313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Dw4-0008Ic-PM for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:03:53 -0400 Received: by wgzl5 with SMTP id l5so37955334wgz.3 for ; Wed, 17 Jun 2015 07:01:58 -0700 (PDT) From: "=?UTF-8?B?S8WRdsOhZ8OzIFpvbHTDoW4=?=" Message-ID: <55817DD8.6060605@gmail.com> Date: Wed, 17 Jun 2015 16:02:00 +0200 MIME-Version: 1.0 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> <87bnge310y.fsf@blackfin.pond.sub.org> In-Reply-To: <87bnge310y.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Kevin Wolf , qemu-devel@nongnu.org, =?UTF-8?B?TMOhc3psw7MgRXJzZWs=?= , Gerd Hoffmann , Michael Roth 2015-06-17 15:41 keltezéssel, Markus Armbruster írta: > "Kővágó Zoltán" writes: > >> 2015-06-17 13:18 keltezéssel, Markus Armbruster írta: >>> 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ászló because his fingerprints are on OptsVisitor. >>>>> >>>>> "Kővágó, Zoltán" 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=44100' 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 >>>>>> 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=0 to set a.foo and b.foo, but foo=x 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? Originally I designed it that way because it allows you to specify frequency=44100 and set both in.frequency and out.frequency. But this could also be the convenience feature that we not really need. I don't see any other downside of making it unambigous.