qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 02/40] blockjob: Improve BlockJobInfo.offset/


From: John Snow
Subject: Re: [Qemu-devel] [PATCH v2 02/40] blockjob: Improve BlockJobInfo.offset/len documentation
Date: Fri, 18 May 2018 13:47:03 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0


On 05/18/2018 09:20 AM, Kevin Wolf wrote:
> Clarify that len is just an estimation of the end value of offset, and
> that offset increases monotonically while len can change arbitrarily.
> 
> Signed-off-by: Kevin Wolf <address@hidden>
> ---
>  qapi/block-core.json | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index d32ec95666..0e29abf099 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1148,7 +1148,12 @@
>  # @device: The job identifier. Originally the device name but other
>  #          values are allowed since QEMU 2.7
>  #
> -# @len: the maximum progress value
> +# @len: Estimated @offset value at the completion of the job. This value can
> +#       arbitrarily change while the job is running, in both directions.
> +#
> +# @offset: Progress made until now. The unit is arbitrary and the value can
> +#          only meaningfully be used for the ratio of @offset to @len. The
> +#          value is monotonically increasing.
>  #
>  # @busy: false if the job is known to be in a quiescent state, with
>  #        no pending I/O.  Since 1.3.
> @@ -1156,8 +1161,6 @@
>  # @paused: whether the job is paused or, if @busy is true, will
>  #          pause itself as soon as possible.  Since 1.3.
>  #
> -# @offset: the current progress value
> -#
>  # @speed: the rate limit, bytes per second
>  #
>  # @io-status: the status of the job (since 1.3)
> 

It matches current actual behavior, so it's probably a good update. It
feels like a change in behavior, but it's rather just codifying the
existing reality.

OK.

Reviewed-by: John Snow <address@hidden>



reply via email to

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