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
