Re: [Qemu-devel] [Qemu-block] [PATCH v2 21/40] job: Convert block_job_cancel_async() to Job

[Kashyap Chamarthy <kchamart@redhat.com>]

On Fri, May 25, 2018 at 10:00:35AM +0200, Kevin Wolf wrote:
> Am 24.05.2018 um 19:42 hat John Snow geschrieben:

[...]

(Randomly chiming in for a small clarification.)

> > >> or some other mechanism that accomplishes the same type of behavior. It
> > >> would be nice if it did not have to be determined at job creation time
> > >> but instead could be determined later.
> > > 
> > > I agree. We already made sure that job-cancel really means cancel on the
> > > QAPI level, so we're free to do that. We just need to keep supporting
> > > block-job-cancel with the old semantics, so what I have is the easy
> > > conversion. We can change the internal implementation when we actually
> > > implement the selection of a completion mode.
> > > 
> > > Kevin
> > > 
> > 
> > We need this before 3.0 though, yeah? unless we make job-cancel
> > x-job-cancel or some other warning that the way it works might change, yeah?
> > 
> > Or do I misunderstand our leeway to change this at a later point in time?
> > 
> > (can job-cancel apply to block jobs created with the legacy
> > infrastructure? My reading was "yes.")
> 
> It can, and it already has its final semantics, so nothing has to change
> before 3.0. job-cancel is equivalent to block-job-cancel with fixed
> force=true. If you want the complete-by-cancel behaviour of mirror, you
> have to use block-job-cancel for now, because job-cancel doesn't provide
> that functionality.

I think by "complete-by-cancel" you are referring to this[*] magic
behaviour, mentioned in the last sentence here:

    When you cancel an in-progress ‘mirror’ job before the source and
    target are synchronized, block-job-cancel will emit the event
    BLOCK_JOB_CANCELLED. However, note that if you cancel a ‘mirror’ job
    after it has indicated (via the event BLOCK_JOB_READY) that the
    source and target have reached synchronization, then the event
    emitted by block-job-cancel changes to BLOCK_JOB_COMPLETED.


[*] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/live-block-operations.rst#l515

> So what we can change later is adding a way to initiate this secondary
> completion mode with a job-* command (probably with a new option for
> job-complete). But we wouldn't change the semantics of exisiting
> commands.

Ah, so if I'm understanding it correctly, the existing subtle magic of
"complete-by-cancel" will be rectified by separting the two distinct
operations: 'job-cancel' and 'job-complete'.


-- 
/kashyap