From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1rhY-0004dL-7q for qemu-devel@nongnu.org; Mon, 08 Jun 2015 03:42:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1rhU-0005iF-AQ for qemu-devel@nongnu.org; Mon, 08 Jun 2015 03:42:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1rhU-0005i8-4o for qemu-devel@nongnu.org; Mon, 08 Jun 2015 03:42:28 -0400 Message-ID: <1433749345.5046.22.camel@redhat.com> From: Gerd Hoffmann Date: Mon, 08 Jun 2015 09:42:25 +0200 In-Reply-To: <5571AA1B.8060800@gmail.com> References: <2e2fabdd19c4c81d40535244813fe42646557089.1433424889.git.DirtY.iCE.hu@gmail.com> <1433431821.3736.52.camel@nilsson.home.kraxel.org> <5570CC69.2060409@gmail.com> <1433501871.4142.9.camel@redhat.com> <5571AA1B.8060800@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v2] qapi for audio backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?K=C5=91v=C3=A1g=C3=B3_Zolt=C3=A1n?= Cc: qemu-devel@nongnu.org On Fr, 2015-06-05 at 15:54 +0200, K=C5=91v=C3=A1g=C3=B3 Zolt=C3=A1n wrote= : > Hi, >=20 > 2015-06-05 12:57 keltez=C3=A9ssel, Gerd Hoffmann =C3=ADrta: > >> Yeah, I've already hit a problem. The opts_visitor doesn't really ha= ndle > >> nested structs (it just flattens it into a single, non hierarchic > >> namespace), which is a problem because of the input and output optio= ns. > >> First I need to make them required (the in and out in Audiodev) if I > >> want the current visitor to visit them at all, but it's still not en= ough. > > > > I think we should improve the visitor instead of making in & out > > mandatory just because the current implementation (which simply > > implements the stuff needed for Netdev) can't handle it. >=20 > It's not that simple I think. The visit_optional only receives a field=20 > name, but no info about the type of the field, but it has to decide if=20 > it wants the field using only this info. So sort of hacking an if=20 > (strcmp(name, "in") =3D=3D 0 || strcmp(name, "out") =3D=3D 0) ... into = the=20 > option visitor code, the only way is probably to add a type parameter t= o=20 > visit_optional (struct/union/uint32/whatever) and in the opts visitor i= f=20 > type is struct or union, force visiting it. Is it ok? Thinking about this a bit more, I suspect it becomes tricky when it comes to allocation. We want allocate *in and *out only in case there are actually parameters for it on the command line. But I think we have to pass something down to the struct visitor (given how visitors are designed). So allocate, pass down, then free again in case nothing was filled? How do we figure nothing was filled, in the generic visit_optional function? Of course we can avoid this complexity by simply allocating *in and *out unconditionally, but then it is pointless to make it optional in the first place. So maybe it is better to go with your original idea to just make them mandatory (and all elements inside optional). cheers, Gerd