Am 18.10.2012 16:52, schrieb Paolo Bonzini:
> 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.
Then let's break the API. Not immediately, I think we can keep some
useless compatibility fields in the implementation of background jobs
that would only be needed to allow the block job commands to be a
wrapper (mostly 'bool is_block_job' and 'BlockDriverState bs', I think;
maybe even just char* bs_name would be enough). Then deprecate block
jobs and at 1.6 or so remove them.
Kevin
