qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: qemu-block@nongnu.org, pkrempa@redhat.com, jtc@redhat.com,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v3 02/14] blockjobs: Add status enum
Date: Mon, 29 Jan 2018 18:04:42 +0100	[thread overview]
Message-ID: <20180129170442.GL6141@localhost.localdomain> (raw)
In-Reply-To: <20180127020515.27137-3-jsnow@redhat.com>

Am 27.01.2018 um 03:05 hat John Snow geschrieben:
> We're about to add several new states, and booleans are becoming
> unwieldly and difficult to reason about. 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.
> CREATED:   replaces (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.
> 
> 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.
>            This status does not feature for non-transactional jobs.
> 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. If this job is in a transaction, it has
>            already left the WAITING status.
> CONCLUDED: Job has ceased all operations and has a return code available
>            for query and may be dismissed via block_job_dismiss.
> Signed-off-by: John Snow <jsnow@redhat.com>

Empty line before S-o-b?

>  blockjob.c               | 10 ++++++++++
>  include/block/blockjob.h |  4 ++++
>  qapi/block-core.json     | 17 ++++++++++++++++-
>  3 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/blockjob.c b/blockjob.c
> index 9850d70cb0..6eb783a354 100644
> --- a/blockjob.c
> +++ b/blockjob.c
> @@ -321,6 +321,7 @@ void block_job_start(BlockJob *job)
>      job->pause_count--;
>      job->busy = true;
>      job->paused = false;
> +    job->status = BLOCK_JOB_STATUS_RUNNING;
>      bdrv_coroutine_enter(blk_bs(job->blk), job->co);
>  }
>  
> @@ -601,6 +602,10 @@ BlockJobInfo *block_job_query(BlockJob *job, Error **errp)
>      info->speed     = job->speed;
>      info->io_status = job->iostatus;
>      info->ready     = job->ready;
> +    if (job->manual) {
> +        info->has_status = true;
> +        info->status = job->status;
> +    }

Why do we want to hide the status from clients that don't want to
complete the job manually? Isn't this conflating two orthogonal things?

>      return info;
>  }
>  
> @@ -704,6 +709,7 @@ void *block_job_create(const char *job_id, const BlockJobDriver *driver,
>      job->pause_count   = 1;
>      job->refcnt        = 1;
>      job->manual        = manual;
> +    job->status        = BLOCK_JOB_STATUS_CREATED;
>      aio_timer_init(qemu_get_aio_context(), &job->sleep_timer,
>                     QEMU_CLOCK_REALTIME, SCALE_NS,
>                     block_job_sleep_timer_cb, job);
> @@ -808,9 +814,12 @@ void coroutine_fn block_job_pause_point(BlockJob *job)
>      }
>  
>      if (block_job_should_pause(job) && !block_job_is_cancelled(job)) {
> +        BlockJobStatus status = job->status;
> +        job->status = BLOCK_JOB_STATUS_PAUSED;
>          job->paused = true;
>          block_job_do_yield(job, -1);
>          job->paused = false;
> +        job->status = status;
>      }
>  
>      if (job->driver->resume) {
> @@ -916,6 +925,7 @@ void block_job_iostatus_reset(BlockJob *job)
>  
>  void block_job_event_ready(BlockJob *job)
>  {
> +    job->status = BLOCK_JOB_STATUS_READY;
>      job->ready = true;
>  
>      if (block_job_is_internal(job)) {
> diff --git a/include/block/blockjob.h b/include/block/blockjob.h
> index b94d0c9fa6..d8e7df7e6e 100644
> --- a/include/block/blockjob.h
> +++ b/include/block/blockjob.h
> @@ -146,6 +146,10 @@ typedef struct BlockJob {
>       */
>      bool manual;
>  
> +    /* Current state, using 2.12+ state names
> +     */
> +    BlockJobStatus status;
> +
>      /** Non-NULL if this job is part of a transaction */
>      BlockJobTxn *txn;
>      QLIST_ENTRY(BlockJob) txn_list;
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 8225308904..eac89754c1 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -955,6 +955,18 @@
>  { 'enum': 'BlockJobType',
>    'data': ['commit', 'stream', 'mirror', 'backup'] }
>  
> +##
> +# @BlockJobStatus:
> +#
> +# Block Job State
> +#
> +#
> +#
> +# Since: 2.12
> +##
> +{ 'enum': 'BlockJobStatus',
> +  'data': ['undefined', 'created', 'running', 'paused', 'ready'] }

I assume these multiple empty lines are left there so you have space to
fill in the information from the commit message?

>  ##
>  # @BlockJobInfo:
>  #
> @@ -981,12 +993,15 @@
>  #
>  # @ready: true if the job may be completed (since 2.2)
>  #
> +# @status: Current job state/status (since 2.12)
> +#
>  # Since: 1.1
>  ##
>  { 'struct': 'BlockJobInfo',
>    'data': {'type': 'str', 'device': 'str', 'len': 'int',
>             'offset': 'int', 'busy': 'bool', 'paused': 'bool', 'speed': 'int',
> -           'io-status': 'BlockDeviceIoStatus', 'ready': 'bool'} }
> +           'io-status': 'BlockDeviceIoStatus', 'ready': 'bool',
> +           '*status': 'BlockJobStatus' } }

If we don't actually have a reason to hide the status above, it can
become a non-opional field here.

Kevin

  reply	other threads:[~2018-01-29 17:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-27  2:05 [Qemu-devel] [RFC v3 00/14] blockjobs: add explicit job management John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 01/14] blockjobs: add manual property John Snow
2018-01-29 16:59   ` Kevin Wolf
2018-01-29 17:34     ` John Snow
2018-01-29 17:46       ` Kevin Wolf
2018-01-29 17:52         ` John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 02/14] blockjobs: Add status enum John Snow
2018-01-29 17:04   ` Kevin Wolf [this message]
2018-01-29 17:38     ` John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 03/14] blockjobs: add state transition table John Snow
2018-01-29 17:17   ` Kevin Wolf
2018-01-29 19:07     ` John Snow
2018-01-29 19:56       ` Kevin Wolf
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 04/14] blockjobs: RFC add block_job_verb permission table John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 05/14] blockjobs: add block_job_dismiss John Snow
2018-01-29 17:38   ` Kevin Wolf
2018-01-29 20:33     ` John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 06/14] blockjobs: add CONCLUDED state John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 07/14] blockjobs: ensure abort is called for cancelled jobs John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 08/14] blockjobs: add commit, abort, clean helpers John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 09/14] blockjobs: add prepare callback John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 10/14] blockjobs: Add waiting event John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 11/14] blockjobs: add PENDING status and event John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 12/14] blockjobs: add block-job-finalize John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 13/14] blockjobs: Expose manual property John Snow
2018-01-27  2:05 ` [Qemu-devel] [RFC v3 14/14] iotests: test manual job dismissal John Snow
2018-01-27  2:25 ` [Qemu-devel] [RFC v3 00/14] blockjobs: add explicit job management no-reply
2018-02-01  0:08 ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180129170442.GL6141@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=jtc@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).