qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 31/45] mirror: add support for on-source-erro


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 31/45] mirror: add support for on-source-error/on-target-error
Date: Fri, 19 Oct 2012 10:04:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

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



reply via email to

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