qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v12 10/19] block: Add QMP support for streaming


From: Alberto Garcia
Subject: Re: [Qemu-block] [PATCH v12 10/19] block: Add QMP support for streaming to an intermediate layer
Date: Thu, 27 Oct 2016 12:08:48 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Thu 27 Oct 2016 10:58:04 AM CEST, Kevin Wolf wrote:
>> >> +# The node that receives the data is called the top image, can be 
>> >> located in
>> >> +# any part of the chain (but always above the base image; see below) and 
>> >> can be
>> >> +# specified using its device or node name.
>> >> +#
>> >>  # If a base file is specified then sectors are not copied from that base 
>> >> file and
>> >>  # its backing chain.  When streaming completes the image file will have 
>> >> the base
>> >>  # file as its backing file.  This can be used to stream a subset of the 
>> >> backing
>> >> @@ -1475,12 +1479,12 @@
>> >>  # @job-id: #optional identifier for the newly-created block job. If
>> >>  #          omitted, the device name will be used. (Since 2.7)
>> >>  #
>> >> -# @device: the device name or node-name of a root node
>> >> +# @device: the device or node name of the top image
>> >>  #
>> >>  # @base:   #optional the common backing file name
>> >>  #
>> >> -# @backing-file: #optional The backing file string to write into the 
>> >> active
>> >> -#                          layer. This filename is not validated.
>> >> +# @backing-file: #optional The backing file string to write into the top
>> >> +#                          image. This filename is not validated.
>> >>  #
>> >>  #                          If a pathname string is such that it cannot be
>> >>  #                          resolved by QEMU, that means that subsequent 
>> >> QMP or
>> >
>> > As we discussed in v10, this is not discoverable through
>> > introspection.  You added patch 18 which introduces a base-node
>> > option and can serve as a witness for the changed semantics, which
>> > is good. Should this be documented here?
>> 
>> In the commit message I don't see why not, but in the JSON file?
>> 
>> "This feature was added together with the base-node parameter" ?
>
> Eric may have a better suggestion for the wording, but maybe something
> like this:
>
> "Presence of this feature can't directly be tested with introspection;
> check for the presence of base-node instead as a witness for it."

Ok, sounds good to me. If there's a next version of the series I will
include that text, else feel free to put it when you commit.

Berto



reply via email to

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