qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] block: Additional info string in ImageInfo


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 1/3] block: Additional info string in ImageInfo and BDI
Date: Thu, 05 Sep 2013 14:52:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

On 2013-09-05 14:25, Eric Blake wrote:
On 09/05/2013 06:05 AM, Max Reitz wrote:
Add a string for additional information to ImageInfo and
BlockDriverInfo. Also, use this string to emit the compatibility level
and lazy_refcount value (on compat=1.1) for qcow2.

Signed-off-by: Max Reitz <address@hidden>
---
+++ b/qapi-schema.json
@@ -238,6 +238,9 @@
  #
  # @backing-image: #optional info of the backing image (since 1.6)
  #
+# @info-string: #optional string supplying additional format-specific
+# information (since 1.7)
+#
  # Since: 1.3
  #
  ##
@@ -248,7 +251,7 @@
             '*cluster-size': 'int', '*encrypted': 'bool',
             '*backing-filename': 'str', '*full-backing-filename': 'str',
             '*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'],
-           '*backing-image': 'ImageInfo' } }
+           '*backing-image': 'ImageInfo', '*info-string': 'str' } }
This may work for HMP, but is LOUSY for use by QMP clients.  If you are
passing back more than a single piece of information, you are now
requiring the QMP client to do a parse of a free-form string to learn
those pieces of information.  I'd much rather see a full JSON schema
where EVERY piece of information passed back gets its own optional
field, or even where the additional information is a union type
discriminated by the image, so that we have full structure of the
information being returned rather than just an ad-hoc blobbed string.

Please rework this so that QMP clients like libvirt can easily probe
what compat mode a qcow2 image uses, without having to parse a free-form
string.

Seems very reasonable; I'll do my best.

Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]