From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bX9sG-0005s2-AO for qemu-devel@nongnu.org; Tue, 09 Aug 2016 12:27:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bX9sE-00026f-7p for qemu-devel@nongnu.org; Tue, 09 Aug 2016 12:27:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bX9sE-00026b-03 for qemu-devel@nongnu.org; Tue, 09 Aug 2016 12:27:26 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9F38D61E46 for ; Tue, 9 Aug 2016 16:27:25 +0000 (UTC) From: Markus Armbruster References: <20160808141439.16908-1-marcandre.lureau@redhat.com> <20160808141439.16908-13-marcandre.lureau@redhat.com> <877fbqglj6.fsf@dusky.pond.sub.org> <393082343.564767.1470747025500.JavaMail.zimbra@redhat.com> <87h9audnik.fsf@dusky.pond.sub.org> <1611724015.610129.1470753690860.JavaMail.zimbra@redhat.com> Date: Tue, 09 Aug 2016 18:27:23 +0200 In-Reply-To: <1611724015.610129.1470753690860.JavaMail.zimbra@redhat.com> (=?utf-8?Q?=22Marc-Andr=C3=A9?= Lureau"'s message of "Tue, 9 Aug 2016 10:41:30 -0400 (EDT)") Message-ID: <87r39x9ac4.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 12/15] monitor: use qmp_dispatch() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau Cc: marcandre lureau , qemu-devel@nongnu.org Marc-Andr=C3=A9 Lureau writes: > Hi > > ----- Original Message ----- >> Marc-Andr=C3=A9 Lureau writes: >>=20 >> > Hi >> > >> > ----- Original Message ----- >> >> marcandre.lureau@redhat.com writes: >> >>=20 >> >> > From: Marc-Andr=C3=A9 Lureau >> >> > >> >> > Replace the old manual dispatch and validation code by the generic = one >> >> > provided by qapi common code. >> >> > >> >> > Note that it is now possible to call the following commands that us= ed to >> >> > be disabled by compile-time conditionals: >> >> > - dump-skeys >> >> > - query-spice >> >> > - rtc-reset-reinjection >> >> > - query-gic-capabilities >> >> > >> >> > Their fallback functions return an appropriate "feature disabled" e= rror. >> >> > >> >> > Signed-off-by: Marc-Andr=C3=A9 Lureau >> >>=20 >> >> Means query-qmp-schema no longer shows whether these commands are >> >> supported, doesn't it? >> >>=20 >> >> Eric, could this create difficulties for libvirt or other introspecti= on >> >> users? >> > >> > Thinking a bit about this, I guess it would be fairly straightforward >> > to have a new key "c-conditional" : "#ifdef CONFIG_SPICE" that would >> > prepend it in C generated files, with a corresponding "#endif". Would >> > that be acceptable? >>=20 >> Not exactly pretty, but the only alternative I can think of right now >> would be conditional qapi generation, i.e. something like >>=20 >> { 'if': 'CONFIG_SPICE' >> 'then': { 'command': 'query-spice', 'returns': 'SpiceInfo' } } >>=20 >> More general, but *much* more work. Let's not go there now. > > That looks quite unnecessarily complicated to me, and not so declarative. > >>=20 >> The value of key 'c-conditional' must be a preprocessing directive that >> pairs with #endif. Hmm. >>=20 >> Could make it an expression instead, and call the key just >> 'conditional'. If given, wrap the code generated for the QAPI >> definition in >>=20 >> #if >> ... >> #endif >>=20 > > Sure, we could make it a preprocessor expression instead, so it would hav= e to match with the automatically appened "#endif". > >> Feels cleaner, but to avoid -Wundef warnings, we'd have to say >> 'defined(CONFIG_SPICE)'. > > Yes, why not? I can work on a patch see how well it fits. Yes, please.