• J
    blockjobs: add status enum · 58b295ba
    John Snow 提交于
    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: NJohn Snow <jsnow@redhat.com>
    Signed-off-by: NKevin Wolf <kwolf@redhat.com>
    58b295ba
109.out 19.5 KB