qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/9] block jobs: Use BdrvChild callbacks for iostatus operations
Date: Tue, 29 Mar 2016 20:15:30 +0200	[thread overview]
Message-ID: <56FAC642.3080606@redhat.com> (raw)
In-Reply-To: <1458675397-24956-4-git-send-email-kwolf@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 3207 bytes --]

On 22.03.2016 20:36, Kevin Wolf wrote:
> The block jobs currently modify the target BB's error handling options
> and require that the source BB's iostatus is enabled in order to
> implement the per-job error options. It's obvious that this is something
> between ugly, adventurous and plain wrong, so we should ideally fix this
> instead of thinking about how to handle multiple BBs in this case.
> 
> Unfortunately we have a chicken-and-egg problem here: In order to fix
> the problem, the block jobs need their own BBs. This requires multiple
> BBs per BDS, which in turn means that BDS.blk must be removed. Removing
> BDS.blk means that the jobs already need their own BB. The only other
> options is that we lift the iostatus operations to the BdrvChild level
> and deal with multiple BBs now.
> 
> So even though we don't want to have these callbacks in the end (because
> they indicate broken logic), this patch converts the iostatus operations
> for block jobs targets to BdrvChild callbacks; if more than one parent
> implements iostatus operations, they are called for each of them.
> 
> Once the conversion is completed, block jobs will get their own internal
> BB and the callbacks can be removed again.
> 
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
>  block/backup.c            | 20 +++++------
>  block/block-backend.c     | 42 +++++++++++++++++++++++
>  block/commit.c            |  2 +-
>  block/mirror.c            | 21 ++++++------
>  block/stream.c            |  2 +-
>  blockjob.c                | 85 +++++++++++++++++++++++++++++++++++++++++++++--
>  include/block/block_int.h | 10 ++++++
>  include/block/blockjob.h  |  9 +++++
>  8 files changed, 165 insertions(+), 26 deletions(-)

[...]

> diff --git a/block/block-backend.c b/block/block-backend.c
> index c4c0dc0..03e68a7 100644
> --- a/block/block-backend.c
> +++ b/block/block-backend.c
> @@ -100,6 +100,39 @@ static const char *blk_root_get_name(BdrvChild *child)
>      return blk_name(child->opaque);
>  }
>  
> +static void blk_root_iostatus_reset(BdrvChild *child)
> +{
> +    return blk_iostatus_reset(child->opaque);

The C11 standard (draft) says in 6.8.6.4 paragraph 1 that:
> A return statement with an expression shall not appear in a function
> whose return type is void.

Even if it is a void expression, it still is an expression. Also, the
semantics of a return statement with an expression is as follows
(paragraph 3):
> If a return statement with an expression is executed, the value of
> the expression is returned to the caller as the value of the function
> call expression.

However, 6.3.2.2 ("void") says:
> The (nonexistent) value of a void expression (an expression that has
> type void) shall not be used in any way

Therefore, the value of a void expression cannot be returned through a
return instruction because such a value does not exist.

I looked it up because I remember you had quite a bit of knowledge
regarding corner cases of the void types. The patch looks good overall,
so if you can point me to why this is allowed or that it's something we
already do somewhere else in qemu, then I'll give my R-b.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-03-29 18:15 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22 19:36 [Qemu-devel] [PATCH 0/9] block: Remove BlockDriverState.blk Kevin Wolf
2016-03-22 19:36 ` [Qemu-devel] [PATCH 1/9] block: Use BdrvChild callbacks for change_media/resize Kevin Wolf
2016-03-29 17:36   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 2/9] block: User BdrvChild callback for device name Kevin Wolf
2016-03-29 17:43   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 3/9] block jobs: Use BdrvChild callbacks for iostatus operations Kevin Wolf
2016-03-29 18:15   ` Max Reitz [this message]
2016-03-22 19:36 ` [Qemu-devel] [PATCH 4/9] block: Remove bdrv_aio_multiwrite() Kevin Wolf
2016-03-29 18:22   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 5/9] block: Avoid BDS.blk in bdrv_next() Kevin Wolf
2016-03-29 18:26   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 6/9] block: Remove bdrv_move_feature_fields() Kevin Wolf
2016-03-29 18:28   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 7/9] block: Avoid bs->blk in bdrv_next() Kevin Wolf
2016-03-29 18:50   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 8/9] block: Don't return throttling info in query-named-block-nodes Kevin Wolf
2016-03-29 18:53   ` Max Reitz
2016-03-22 19:36 ` [Qemu-devel] [PATCH 9/9] block: Remove BlockDriverState.blk Kevin Wolf
2016-03-29 18:59   ` Max Reitz
2016-03-22 21:34 ` [Qemu-devel] [PATCH 0/9] " Paolo Bonzini

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=56FAC642.3080606@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@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).