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: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 02/40] blockjob: Improve BlockJobInfo.offset/len documentation
Date: Fri, 18 May 2018 09:25:43 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 05/18/2018 08: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.

That's tighter than what libvirt promises (and in fact, there are cases where libvirt synthesizes an offset/len of 1/1 to indicate completion when the information is no longer available from qemu, which means the offset has gone backwards to libvirt clients).

But it matches the qemu implementation, and I'm okay if we want to stick to those semantics of monotonically increasing offset (the more important semantics of being an estimate of time remaining is possible whether or not you have a guarantee of a monotonic increase on one of the two numbers).


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.

So I'm okay whether or not you drop that last sentence.

You're also rearranging the docs to occur in the order that the struct declares things (good change, and trivial; not sure if you want to call it out in the commit message).

Reviewed-by: Eric Blake <address@hidden>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

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