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 01/14] blockjobs: add manual property
Date: Mon, 29 Jan 2018 17:59:29 +0100	[thread overview]
Message-ID: <20180129165929.GK6141@localhost.localdomain> (raw)
In-Reply-To: <20180127020515.27137-2-jsnow@redhat.com>

Am 27.01.2018 um 03:05 hat John Snow geschrieben:
> This property will be used to opt-in to the new BlockJobs workflow
> that allows a tighter, more explicit control over transitions from
> one runstate to another.
> 
> Signed-off-by: John Snow <jsnow@redhat.com>

> diff --git a/include/block/blockjob.h b/include/block/blockjob.h
> index 00403d9482..b94d0c9fa6 100644
> --- a/include/block/blockjob.h
> +++ b/include/block/blockjob.h
> @@ -141,6 +141,11 @@ typedef struct BlockJob {
>       */
>      QEMUTimer sleep_timer;
>  
> +    /* Set to true when management API has requested 2.12+ job lifetime
> +     * management semantics.
> +     */
> +    bool manual;

Wouldn't it make more sense to describe what "2.12+ job lifetime
management semantics" actually are? Maybe then it would be easy to find
a more specific name, too, like manual_completion.

In fact, I wonder if the opposite flag wouldn't be nicer, i.e. having a
bool auto_completion (or finalization or whatever that extra step was
called in the final draft), defaulting to true.

Also, the comment style in this header is already pretty messed up, but
I think the styles that were originally meant to be used there, are

    /** this one for single lines */

    /**
     * and this one if things get a bit longer
     * and you need multiple lines.
     */

Kevin

  reply	other threads:[~2018-01-29 16:59 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 [this message]
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
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=20180129165929.GK6141@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).