From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXCon-0005xF-TW for qemu-devel@nongnu.org; Tue, 09 Aug 2016 15:36:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXCom-0001xv-GH for qemu-devel@nongnu.org; Tue, 09 Aug 2016 15:36:05 -0400 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:34262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXCom-0001xr-4r for qemu-devel@nongnu.org; Tue, 09 Aug 2016 15:36:04 -0400 Received: by mail-wm0-x244.google.com with SMTP id q128so5218056wma.1 for ; Tue, 09 Aug 2016 12:36:03 -0700 (PDT) MIME-Version: 1.0 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> <87r39x9ac4.fsf@dusky.pond.sub.org> In-Reply-To: <87r39x9ac4.fsf@dusky.pond.sub.org> From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Tue, 09 Aug 2016 19:35:52 +0000 Message-ID: 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: Markus Armbruster Cc: qemu-devel@nongnu.org Hi On Tue, Aug 9, 2016 at 9:35 PM Markus Armbruster wrote: > Marc-Andr=C3=A9 Lureau writes: > > > Hi > > > > ----- Original Message ----- > >> Marc-Andr=C3=A9 Lureau writes: > >> > >> > Hi > >> > > >> > ----- Original Message ----- > >> >> marcandre.lureau@redhat.com writes: > >> >> > >> >> > From: Marc-Andr=C3=A9 Lureau > >> >> > > >> >> > Replace the old manual dispatch and validation code by the generi= c > one > >> >> > provided by qapi common code. > >> >> > > >> >> > Note that it is now possible to call the following commands that > used 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" > error. > >> >> > > >> >> > Signed-off-by: Marc-Andr=C3=A9 Lureau > >> >> > >> >> Means query-qmp-schema no longer shows whether these commands are > >> >> supported, doesn't it? > >> >> > >> >> Eric, could this create difficulties for libvirt or other > introspection > >> >> users? > >> > > >> > Thinking a bit about this, I guess it would be fairly straightforwar= d > >> > to have a new key "c-conditional" : "#ifdef CONFIG_SPICE" that would > >> > prepend it in C generated files, with a corresponding "#endif". Woul= d > >> > that be acceptable? > >> > >> Not exactly pretty, but the only alternative I can think of right now > >> would be conditional qapi generation, i.e. something like > >> > >> { 'if': 'CONFIG_SPICE' > >> 'then': { 'command': 'query-spice', 'returns': 'SpiceInfo' } } > >> > >> More general, but *much* more work. Let's not go there now. > > > > That looks quite unnecessarily complicated to me, and not so declarativ= e. > > > >> > >> The value of key 'c-conditional' must be a preprocessing directive tha= t > >> pairs with #endif. Hmm. > >> > >> Could make it an expression instead, and call the key just > >> 'conditional'. If given, wrap the code generated for the QAPI > >> definition in > >> > >> #if > >> ... > >> #endif > >> > > > > Sure, we could make it a preprocessor expression instead, so it would > have 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. > After spending some time on this (the generator part is trivial), I think it's not going to be that easy because the conditions are per-target, but qmp is not, so you get poisoned defines errors with the TARGET conditions. We can't easily make qmp per target, as the code is spread everywhere (even though such qmp code won't be useful for other tools, it would be nice to untangle this - the block code is full of qmp usage and implementation) Furthermore, the current query-qmp-schema returns all commands currently, so this won't be a regression. I imagine 3 ways to solve this: - make qmp code per-target (seems to be pretty intrusive change all over, although I think it's nicer. As a simple ex, calling qmp_query_uuid() just to get an uuid doesn't make much sense, it doesn't have to go through qmp) - unregister functions dynamically? (that could be useful for other reasons= ) - make only qmp_init_marshal() and qmp_introspect() per target. That last option seems the easier. What do you think? --=20 Marc-Andr=C3=A9 Lureau