qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v4 07/21] blockjobs: add block_job_verb permission


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC v4 07/21] blockjobs: add block_job_verb permission table
Date: Tue, 27 Feb 2018 18:19:34 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

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 <address@hidden>

Reviewed-by: Kevin Wolf <address@hidden>



reply via email to

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