Am 24.02.2018 um 00:51 hat John Snow geschrieben:
> Which commands ("verbs") are appropriate for jobs in which state is
> also somewhat burdensome to keep track of.
>
> As of this commit, it looks rather useless, but begins to look more
> interesting the more states we add to the STM table.
>
> A recurring theme is that no verb will apply to an 'undefined' job.
>
> Further, it's not presently possible to restrict the "pause" or "resume"
> verbs any more than they are in this commit because of the asynchronous
> nature of how jobs enter the PAUSED state; justifications for some
> seemingly erroneous applications are given below.
>
> =====
> Verbs
> =====
>
> Cancel: Any state except undefined.
> Pause: Any state except undefined;
> 'created': Requests that the job pauses as it starts.
> 'running': Normal usage. (PAUSED)
> 'paused': The job may be paused for internal reasons,
> but the user may wish to force an indefinite
> user-pause, so this is allowed.
> 'ready': Normal usage. (STANDBY)
> 'standby': Same logic as above.
> Resume: Any state except undefined;
> 'created': Will lift a user's pause-on-start request.
> 'running': Will lift a pause request before it takes effect.
> 'paused': Normal usage.
> 'ready': Will lift a pause request before it takes effect.
> 'standby': Normal usage.
> Set-speed: Any state except undefined, though ready may not be meaningful.
> Complete: Only a 'ready' job may accept a complete request.
>
>
> =======
> Changes
> =======
>
> (1)
>
> To facilitate "nice" error checking, all five major block-job verb
> interfaces in blockjob.c now support an errp parameter:
>
> - block_job_user_cancel is added as a new interface.
> - block_job_user_pause gains an errp paramter
> - block_job_user_resume gains an errp parameter
> - block_job_set_speed already had an errp parameter.
> - block_job_complete already had an errp parameter.
>
> (2)
>
> block-job-pause and block-job-resume will no longer no-op when trying
> to pause an already paused job, or trying to resume a job that isn't
> paused. These functions will now report that they did not perform the
> action requested because it was not possible.
>
> iotests have been adjusted to address this new behavior.
>
> (3)
>
> block-job-complete doesn't worry about checking !block_job_started,
> because the permission table guards against this.
>
> (4)
>
> test-bdrv-drain's job implementation needs to announce that it is
> 'ready' now, in order to be completed.
>
> Signed-off-by: John Snow <js...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
