Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/4] blockjobs: add explicit job reaping

[Markus Armbruster]

Quick drive-by comment:

Kevin Wolf <address@hidden> writes:

[...]
> Let me try to just consolidate all of the above into a single state
> machine:
>
> 1.  CREATED --> RUNNING
>         driver callback: .start
> 2a. RUNNING --> READY | CANCELLED
>         via: auto transition (when bulk copy is finished) / block-job-cancel
>         event: BLOCK_JOB_READY
> 2b. READY --> READY (COMPLETING) | READY (CANCELLING)
>         via: block-job-complete / block-job-cancel
>         event: none
>         driver callback: .complete / none
> 3.  READY (CANCELLING | COMPLETING) --> DONE
>         via: auto transition
>              (CANCELLING: after draining in-flight mirror requests;
>               COMPLETING: when images are in sync)
>         event: BLOCK_JOB_DONE
> 4.  DONE --> PENDING
>         via: auto transition (all jobs in the transaction are DONE)
>         event: BLOCK_JOB_PENDING
> 5.  PENDING --> FINISHED
>         via: block-job-finalize
>         event: COMPLETED | CANCELLED
>         driver callback: .prepare_finalize / .commit / .abort
> 6.  FINISHED --> NULL
>         via: block-job-reap
>         event: none
>         driver callback: .clean
>
> I removed COMPLETED/CANCELLED states because they are never externally
> visible. You proposed an "auto transition" there, but the transition
> would be immediately after the previous one, so clients always see
> PENDING --> NULL | FINISHED.
>
> We would have two booleans to make explicit transition automatically:
>
>     auto-finalize for block-job-finalize (default: true)
>     auto-reap     for block-job-reap     (default: true)

Are we *sure* we need to quadruple the test matrix?

What exactly is the use case for either of these two flags?

> Both of them would be executed automatically as soon as the respective
> commands would be available.
>
> We could add more auto-* options for the remaining explicit transition

*groan*

> (block-job-complete/cancel in READY), but these are not important for
> the problems we're trying to solve here. They might become interesting
> if we do decide that we want a single copy block job instead of doing
> similar things in mirror, commit and backup.
> The naming needs some improvements (done -> pending -> finished looks
> really odd), but does this make sense otherwise?
>
> Kevin