From: Eric Blake <eblake@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] Support streaming to an intermediate layer
Date: Fri, 20 Feb 2015 15:49:05 -0700 [thread overview]
Message-ID: <54E7B9E1.80807@redhat.com> (raw)
In-Reply-To: <20150220190518.GA2917@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]
On 02/20/2015 12:05 PM, Alberto Garcia wrote:
> On Fri, Feb 20, 2015 at 10:34:58AM -0700, Eric Blake wrote:
>
>>> I followed the proposed API from the wiki, which simply adds an
>>> additional 'top' parameter to block-stream specifying the image
>>> that data is written to:
>>
>> How does one learn whether qemu is new enough to support this
>> mode? Until we add QMP introspection, learning whether an optional
>> parameter exists requires attempting the command and seeing a
>> different error depending on whether the argument is recognized.
>
> Isn't it possible to just check the QEMU version number?
Absolutely not. Vendors are very likely to backport this to earlier
version numbers. Feature probes are ALWAYS a better idea than version
probes.
>
> If not, what's the recommended way to do it?
Several design possibilities, but not all of them feasible at the moment.
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.
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) (on the other hand, if we are going to frame
'stream' in terms of node operations instead of file name operations,
this may be the best idea after all)
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,
then libvirt could use that as a poor-man's probe for the functionality
existing. (ugly, and only works if you can guarantee a difference in
error type between old and new qemu for a specific bogus command usage)
Precedent: we do this sort of bogus command call on 'block-commit' to
learn if qemu is new enough to support active commit, and the comments
in the qemu code are explicit that a particular error message must not
be changed because libvirt depends on it.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-02-20 22:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 13:53 [Qemu-devel] [PATCH 0/3] Support streaming to an intermediate layer Alberto Garcia
2015-02-20 13:53 ` [Qemu-devel] [PATCH 1/3] block: " Alberto Garcia
2015-03-05 14:04 ` Kevin Wolf
2015-03-05 14:58 ` Alberto Garcia
2015-03-05 15:15 ` Kevin Wolf
2015-03-05 15:47 ` Alberto Garcia
2015-03-12 13:18 ` Alberto Garcia
2015-02-20 13:53 ` [Qemu-devel] [PATCH 2/3] block: Add QMP support for " Alberto Garcia
2015-02-20 22:38 ` Eric Blake
2015-02-23 12:23 ` Alberto Garcia
2015-02-23 13:04 ` Kevin Wolf
2015-02-24 14:08 ` Markus Armbruster
2015-03-05 14:09 ` Kevin Wolf
2015-03-05 15:12 ` Alberto Garcia
2015-03-11 16:38 ` Alberto Garcia
2015-03-12 15:45 ` Kevin Wolf
2015-03-17 15:00 ` Alberto Garcia
2015-03-17 15:22 ` Eric Blake
2015-03-17 15:40 ` Alberto Garcia
2015-03-17 15:28 ` Kevin Wolf
2015-03-18 12:29 ` Alberto Garcia
2015-02-20 13:53 ` [Qemu-devel] [PATCH 3/3] docs: Document how to stream " Alberto Garcia
2015-02-20 17:34 ` [Qemu-devel] [PATCH 0/3] Support streaming " Eric Blake
2015-02-20 19:05 ` Alberto Garcia
2015-02-20 22:49 ` Eric Blake [this message]
2015-02-22 15:08 ` Alberto Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E7B9E1.80807@redhat.com \
--to=eblake@redhat.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).