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
signature.asc
Description: OpenPGP digital signature