From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPY9G-0007lr-7R for qemu-devel@nongnu.org; Sun, 22 Feb 2015 10:08:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YPY9D-0002Hz-0U for qemu-devel@nongnu.org; Sun, 22 Feb 2015 10:08:46 -0500 Received: from smtp3.mundo-r.com ([212.51.32.191]:53163 helo=smtp4.mundo-r.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YPY9C-0002Ef-Pc for qemu-devel@nongnu.org; Sun, 22 Feb 2015 10:08:42 -0500 Date: Sun, 22 Feb 2015 16:08:04 +0100 From: Alberto Garcia Message-ID: <20150222150804.GA29581@igalia.com> References: <54E77042.8010207@redhat.com> <20150220190518.GA2917@igalia.com> <54E7B9E1.80807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E7B9E1.80807@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/3] Support streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi On Fri, Feb 20, 2015 at 03:49:05PM -0700, Eric Blake wrote: Hello and thanks for your comments. > 1. implement QAPI introspection (we've been dreaming about this > since qemu 1.5 days), then the caller just queries to see if the > version of QMP has the optional 'top' parameter. This sounds like the best option. Is there a roadmap? What's the status? I guess the amount of work depends a lot on the goals, but from what I can see, something like a 'query-command-args' command that returns the list of parameters is trivial, there's already the qmp_cmds array in memory with all the necessary information. > 2. implement the new feature as a new command (then the existing > 'query-commands' becomes an easy probe; but we have code duplication > with existing commands) I don't think there would be a lot of code duplication because one operation is a strict superset of the other, we would be just adding unnecessary commands. I would go for option 1) if possible. > 3. guarantee that we have sane error messages for bogus > commands used as the probe. If {"execute":"block-stream", > "data":{"device":"no-such","top":"bogus"}} gives a reliable > DeviceNotFound error for qemu that supports optional 'top', and a > reliable GenericError about an unknown argument 'top' in older qemu It doesn't seem like the best solution considering the alternatives, but for what it's worth: Current QEMU: (QEMU) block-stream device=no-such top=bogus {u'error': {u'class': u'GenericError', u'desc': u"Invalid parameter 'top'"}} With my patch: (QEMU) block-stream device=no-such top=bogus {u'error': {u'class': u'DeviceNotFound', u'desc': u"Device 'no-such' not found"}} Regards, Berto