qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Hanna Reitz <hreitz@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Markus Armbruster <armbru@redhat.com>,
	Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH 2/4] block: Add protocol-specific image info
Date: Wed, 4 May 2022 10:36:22 +0200	[thread overview]
Message-ID: <YnI7Bt3bVzUpBzVt@redhat.com> (raw)
In-Reply-To: <20220503145529.37070-3-hreitz@redhat.com>

Am 03.05.2022 um 16:55 hat Hanna Reitz geschrieben:
> The ImageInfo object currently only contains (optional) format-specific
> image information.  However, perhaps the protocol node can provide some
> additional information, so add a new field presenting it.
> 
> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
> ---
>  qapi/block-core.json |  6 +++++-
>  block/qapi.c         | 19 +++++++++++++++++++
>  2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index beeb91952a..e7d6c2e0cc 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -236,6 +236,9 @@
>  # @format-specific: structure supplying additional format-specific
>  #                   information (since 1.7)
>  #
> +# @protocol-specific: structure supplying additional protocol-specific
> +#                     information (since 7.1)
> +#
>  # Since: 1.3
>  #
>  ##
> @@ -246,7 +249,8 @@
>             '*backing-filename': 'str', '*full-backing-filename': 'str',
>             '*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'],
>             '*backing-image': 'ImageInfo',
> -           '*format-specific': 'ImageInfoSpecific' } }
> +           '*format-specific': 'ImageInfoSpecific',
> +           '*protocol-specific': 'ImageInfoSpecific' } }

I'm not a fan of this one. It solves the problem for exactly one special
case (even if admittedly a common one) and leaves everything else as it
is. It is unclear what it produces in configurations that aren't the
simple one format node on top of one protocol node layout.

I would rather interpret 'format-specific' as 'driver-specific' and make
the ImageInfo for any child node accessible.

With rbd we already interpret it like a generic driver thing that is not
just for formats that because it implements .bdrv_get_specific_info even
though we didn't have a 'protocol-specific' yet.

Making other nodes has precedence, too. 'backing-image' is even in the
context of this hunk. VMDK exposes its extents the same way. So maybe
what we really want is a 'children' list with the ImageInfo of every
child node. And then qemu-img could go through all children and print
headings like "Driver specific information for file (#block123)". Then
filters like blkdebug could add their information and it would be
printed, too.

>  ##
>  # @ImageCheck:
> diff --git a/block/qapi.c b/block/qapi.c
> index 51202b470a..293983cf82 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @@ -262,6 +262,7 @@ void bdrv_query_image_info(BlockDriverState *bs,
>      int64_t size;
>      const char *backing_filename;
>      BlockDriverInfo bdi;
> +    BlockDriverState *protocol_bs;
>      int ret;
>      Error *err = NULL;
>      ImageInfo *info;
> @@ -303,6 +304,24 @@ void bdrv_query_image_info(BlockDriverState *bs,
>      }
>      info->has_format_specific = info->format_specific != NULL;
>  
> +    /* Try to look for an unambiguous protocol node */
> +    protocol_bs = bs;
> +    while (protocol_bs && !QLIST_EMPTY(&protocol_bs->children)) {
> +        protocol_bs = bdrv_primary_bs(protocol_bs);
> +    }

If bs is already a leaf node, this duplicates the information, which
looks weird:

    $ build/qemu-img info -f file ~/tmp/test.raw
    image: /home/kwolf/tmp/test.raw
    file format: file
    virtual size: 10 GiB (10737418240 bytes)
    disk size: 7.63 GiB
    Format specific information:
        extent size: 1048576
    Protocol specific information:
        extent size: 1048576

>
> +    if (protocol_bs) {
> +        /* Assert that this is a protocol node */
> +        assert(QLIST_EMPTY(&protocol_bs->children));
> +
> +        info->protocol_specific = bdrv_get_specific_info(protocol_bs, &err);
> +        if (err) {
> +            error_propagate(errp, err);
> +            qapi_free_ImageInfo(info);
> +            goto out;
> +        }
> +        info->has_protocol_specific = info->protocol_specific != NULL;
> +    }
> +
>      backing_filename = bs->backing_file;
>      if (backing_filename[0] != '\0') {
>          char *backing_filename2;

Kevin



  parent reply	other threads:[~2022-05-04  8:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03 14:55 [PATCH 0/4] block/file: Show extent size in qemu-img info Hanna Reitz
2022-05-03 14:55 ` [PATCH 1/4] block: Improve empty format-specific info dump Hanna Reitz
2022-05-03 18:44   ` Eric Blake
2022-05-04  8:18   ` Kevin Wolf
2022-05-03 14:55 ` [PATCH 2/4] block: Add protocol-specific image info Hanna Reitz
2022-05-03 18:47   ` Eric Blake
2022-05-04  8:36   ` Kevin Wolf [this message]
2022-05-04 11:25     ` Hanna Reitz
2022-05-03 14:55 ` [PATCH 3/4] block: Print protocol-specific information Hanna Reitz
2022-05-03 18:48   ` Eric Blake
2022-05-03 14:55 ` [PATCH 4/4] block/file: Add file-specific image info Hanna Reitz
2022-05-03 18:50   ` Eric Blake
2022-05-04  7:10     ` Hanna Reitz
2022-05-04  8:46   ` Kevin Wolf
2022-05-04 11:26     ` Hanna Reitz

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=YnI7Bt3bVzUpBzVt@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@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).