[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC v4 04/21] blockjobs: add status enum
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [RFC v4 04/21] blockjobs: add status enum |
Date: |
Tue, 27 Feb 2018 18:19:02 +0100 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
Am 24.02.2018 um 00:51 hat John Snow geschrieben:
> We're about to add several new states, and booleans are becoming
> unwieldly and difficult to reason about. It would help to have a
> more explicit bookkeeping of the state of blockjobs. To this end,
> add a new "status" field and add our existing states in a redundant
> manner alongside the bools they are replacing:
>
> UNDEFINED: Placeholder, default state. Not currently visible to QMP
> unless changes occur in the future to allow creating jobs
> without starting them via QMP.
> CREATED: replaces !!job->co && paused && !busy
> RUNNING: replaces effectively (!paused && busy)
> PAUSED: Nearly redundant with info->paused, which shows pause_count.
> This reports the actual status of the job, which almost always
> matches the paused request status. It differs in that it is
> strictly only true when the job has actually gone dormant.
> READY: replaces job->ready.
> STANDBY: Paused, but job->ready is true.
>
> New state additions in coming commits will not be quite so redundant:
>
> WAITING: Waiting on transaction. This job has finished all the work
> it can until the transaction converges, fails, or is canceled.
> PENDING: Pending authorization from user. This job has finished all the
> work it can until the job or transaction is finalized via
> block_job_finalize. This implies the transaction has converged
> and left the WAITING phase.
> ABORTING: Job has encountered an error condition and is in the process
> of aborting.
> CONCLUDED: Job has ceased all operations and has a return code available
> for query and may be dismissed via block_job_dismiss.
> NULL: Job has been dismissed and (should) be destroyed. Should never
> be visible to QMP.
>
> Some of these states appear somewhat superfluous, but it helps define the
> expected flow of a job; so some of the states wind up being synchronous
> empty transitions. Importantly, jobs can be in only one of these states
> at any given time, which helps code and external users alike reason about
> the current condition of a job unambiguously.
>
> Signed-off-by: John Snow <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
- Re: [Qemu-block] [RFC v4 18/21] blockjobs: add block-job-finalize, (continued)
- [Qemu-block] [RFC v4 02/21] blockjobs: model single jobs as transactions, John Snow, 2018/02/23
- [Qemu-block] [RFC v4 03/21] blockjobs: add manual property, John Snow, 2018/02/23
- [Qemu-block] [RFC v4 04/21] blockjobs: add status enum, John Snow, 2018/02/23
- [Qemu-block] [RFC v4 11/21] blockjobs: add block_job_dismiss, John Snow, 2018/02/23
- [Qemu-block] [RFC v4 17/21] blockjobs: add PENDING status and event, John Snow, 2018/02/23
- Re: [Qemu-block] [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management, no-reply, 2018/02/23
- Re: [Qemu-block] [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management, no-reply, 2018/02/24