From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:36636)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1QhImx-0007H6-L7
	for qemu-devel@nongnu.org; Thu, 14 Jul 2011 06:05:05 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1QhImt-0006cA-4a
	for qemu-devel@nongnu.org; Thu, 14 Jul 2011 06:04:59 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39624)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1QhIms-0006c5-MF
	for qemu-devel@nongnu.org; Thu, 14 Jul 2011 06:04:55 -0400
Message-ID: <4E1EBFEC.6060606@redhat.com>
Date: Thu, 14 Jul 2011 12:07:40 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <4E131D0D.307@redhat.com>	<20110711125432.GA19686@stefanha-thinkpad.localdomain>	<CAJSP0QX0ksga-bPPy53SPcPaApT5uXfH-8ORtT0JkPRaskBkhg@mail.gmail.com>	<20110711163226.GA10924@amt.cnet>	<4E1C009C.1010408@redhat.com>	<CAJSP0QXwEY7wKYD=vQf1H4nLKzccemNSbNauaMSK8GQgoHrbfw@mail.gmail.com>	<4E1C71F2.4030507@redhat.com>	<CAJSP0QWNW_0oJoKZerPoPXYmGV=fSussabYXNfHFnsNnC9o=xA@mail.gmail.com>	<CAJSP0QUcprRd7sO=v9gHnB7B57jKhg=yX=wwiQUzHR1e8O1x-A@mail.gmail.com>	<4E1EBD24.9090308@redhat.com>
	<CAJSP0QXOA-qvWegnfYOHS7BnUNDS811r467ogN825ZyDJ0Hf1A@mail.gmail.com>
In-Reply-To: <CAJSP0QXOA-qvWegnfYOHS7BnUNDS811r467ogN825ZyDJ0Hf1A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] live block copy/stream/snapshot discussion
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Dor Laor <dlaor@redhat.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>, Adam Litke <agl@us.ibm.com>

Am 14.07.2011 12:00, schrieb Stefan Hajnoczi:
> On Thu, Jul 14, 2011 at 10:55 AM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 14.07.2011 11:39, schrieb Stefan Hajnoczi:
>>>  Events:
>>>
>>>  On completion the BLOCK_STREAM_COMPLETED event is raised with the following
>>>  fields:
>>>
>>>  - device: device name (json-string)
>>>  - len:    size of the device, in bytes (json-int)
>>>  - offset: last offset of completed I/O, in bytes (json-int)
>>>  - error:  error message (json-string, only on error)
>>>
>>>  The completion event is raised both on success and on failure.
>>
>> Why do len/offset matter in a completion event?
> 
> For completeness.  You could see it as telling you how much progress
> was made before an error occurred.  In the success case offset will
> always be equal to len.  But in the error case you get the last
> completed progress before error, which could be useful (for example if
> you weren't polling but want to display "Streaming virtio-blk0 failed
> at 33%").

Makes sense.

We also need to define the possible error messages, and probably use an
enum instead of a string.

Kevin