From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOrSh-0001v1-5L for qemu-devel@nongnu.org; Thu, 18 Oct 2012 10:52:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TOrSX-0000FQ-Jq for qemu-devel@nongnu.org; Thu, 18 Oct 2012 10:52:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TOrSX-0000Ez-BR for qemu-devel@nongnu.org; Thu, 18 Oct 2012 10:52:29 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9IEqSYS005156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Oct 2012 10:52:28 -0400 Message-ID: <508017A3.4050600@redhat.com> Date: Thu, 18 Oct 2012 16:52:19 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1348675011-8794-1-git-send-email-pbonzini@redhat.com> <1348675011-8794-32-git-send-email-pbonzini@redhat.com> <507FFF21.2090007@redhat.com> <507FFFC7.2090800@redhat.com> <50800A92.4070005@redhat.com> In-Reply-To: <50800A92.4070005@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 31/45] mirror: add support for on-source-error/on-target-error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: jcody@redhat.com, qemu-devel@nongnu.org Il 18/10/2012 15:56, Kevin Wolf ha scritto: > Am 18.10.2012 15:10, schrieb Paolo Bonzini: >> Il 18/10/2012 15:07, Kevin Wolf ha scritto: >>>>> + s->synced = false; >>>>> + if (read) { >>>>> + return block_job_error_action(&s->common, s->common.bs, >>>>> + s->on_source_error, true, error); >>>>> + } else { >>>>> + return block_job_error_action(&s->common, s->target, >>>>> + s->on_target_error, false, error); >>> Here we produce an event that reports an error on s->bs, i.e. on the >>> source, even though the error was on the target. >> >> More precisely, this is an event that reports an error on s->bs's job. >> In principle there is no reason why asynchronous long-running operations >> are tied to a block device (in fact migration fits the definition quite >> well, with the only twist that the VM is stopped at the end), but that's >> the API we're stuck with. > > Yes, I think I mentioned already more than once that it shouldn't be > block job, but background job without a reference to a (single) > BlockDriverState. What we have just doesn't make any sense - even for > block jobs, because block jobs working on a single BDS are the > exception, not the rule. I'm quite at a loss with how to change this without breaking the API. :/ Unfortunately this came up after the first release with streaming. Paolo