[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC v4 07/21] blockjobs: add block_job_verb permission
Re: [Qemu-block] [RFC v4 07/21] blockjobs: add block_job_verb permission table
Tue, 27 Feb 2018 18:19:34 +0100
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.
> 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.
> 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.
> 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.
> block-job-complete doesn't worry about checking !block_job_started,
> because the permission table guards against this.
> test-bdrv-drain's job implementation needs to announce that it is
> 'ready' now, in order to be completed.
> Signed-off-by: John Snow <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
[Qemu-block] [RFC v4 07/21] blockjobs: add block_job_verb permission table, John Snow, 2018/02/23
[Qemu-block] [RFC v4 01/21] blockjobs: fix set-speed kick, John Snow, 2018/02/23
[Qemu-block] [RFC v4 08/21] blockjobs: add ABORTING state, John Snow, 2018/02/23
[Qemu-block] [RFC v4 12/21] blockjobs: ensure abort is called for cancelled jobs, John Snow, 2018/02/23