From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Markus Armbruster <armbru@redhat.com>
Cc: "fam@euphon.net" <fam@euphon.net>,
"kwolf@redhat.com" <kwolf@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"mreitz@redhat.com" <mreitz@redhat.com>,
Denis Lunev <den@virtuozzo.com>,
Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>,
"jsnow@redhat.com" <jsnow@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap directory entries
Date: Mon, 4 Feb 2019 11:33:05 -0600 [thread overview]
Message-ID: <eb0487a2-a9f3-22a5-3a4a-e61902269bdb@redhat.com> (raw)
In-Reply-To: <175fb7e8-eec3-8031-55c9-b859ce8f6af0@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
On 2/4/19 10:46 AM, Vladimir Sementsov-Ogievskiy wrote:
>>
>> Oops, hm, I now doubt, how Andrey's patches work, if bitmap_list_load function
>> fails when unknown flags are found. So, can we really show unknown-flags,
>> or we'll fail if there any?
>>
>> And if we fail (I hope we fail) on unknown flags, than we don't need this
>> field :).
>>
>
> But we can update bitmap_list_load, to have a flag, and show bitmaps with
> unknown flags in qemu-img info.. And we have to somehow not fail on open before
> it. I'm very sorry that I understand it all only now :(.
>
> So, do we really need unknown-flags field? If yes, may be, do it as a next step?
> And proceed now without them?
Good point about not even being able to open an image with unknown flags
to be able to report on it (qemu-img check might want to be able to do
it, but if qemu-img info refuses to open the image because of unknown
flags, that's acceptable). I'm good with your idea of skipping
unknown-flags for now, and adding it in a later patch if it proves
worthwhile.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-02-04 17:38 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 13:46 [Qemu-devel] [PATCH v11 0/3] qemu-img info lists bitmap directory entries Andrey Shinkevich
2019-01-31 13:46 ` [Qemu-devel] [PATCH v11 1/3] bdrv_query_image_info Error parameter added Andrey Shinkevich
2019-02-01 14:42 ` Vladimir Sementsov-Ogievskiy
2019-02-01 14:46 ` Daniel P. Berrangé
2019-02-01 17:13 ` Kevin Wolf
2019-01-31 13:46 ` [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap directory entries Andrey Shinkevich
2019-02-01 15:19 ` Vladimir Sementsov-Ogievskiy
2019-02-01 17:08 ` Eric Blake
2019-02-01 17:19 ` Kevin Wolf
2019-02-01 18:39 ` Markus Armbruster
2019-02-01 19:04 ` Eric Blake
2019-02-01 19:23 ` Markus Armbruster
2019-02-01 19:28 ` Eric Blake
2019-02-04 13:05 ` Markus Armbruster
2019-02-04 16:03 ` Vladimir Sementsov-Ogievskiy
2019-02-04 16:24 ` Eric Blake
2019-02-04 16:35 ` Vladimir Sementsov-Ogievskiy
2019-02-04 16:46 ` Vladimir Sementsov-Ogievskiy
2019-02-04 17:33 ` Eric Blake [this message]
2019-02-04 17:37 ` Eric Blake
2019-02-04 7:49 ` Vladimir Sementsov-Ogievskiy
2019-02-04 15:23 ` Eric Blake
2019-02-04 9:46 ` Kevin Wolf
2019-02-04 13:45 ` Markus Armbruster
2019-02-04 15:36 ` Vladimir Sementsov-Ogievskiy
2019-02-05 10:00 ` Kevin Wolf
2019-02-05 13:16 ` Vladimir Sementsov-Ogievskiy
2019-02-05 14:28 ` Kevin Wolf
2019-02-05 14:38 ` Eric Blake
2019-01-31 13:46 ` [Qemu-devel] [PATCH v11 3/3] qemu-img info: bitmaps extension new test 239 Andrey Shinkevich
2019-02-01 15:57 ` Vladimir Sementsov-Ogievskiy
2019-02-01 17:14 ` Kevin Wolf
2019-02-04 7:53 ` Vladimir Sementsov-Ogievskiy
2019-02-04 9:36 ` Kevin Wolf
2019-02-01 17:23 ` Eric Blake
2019-02-01 17:34 ` Kevin Wolf
2019-02-03 15:28 ` [Qemu-devel] [PATCH v11 0/3] qemu-img info lists bitmap directory entries no-reply
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=eb0487a2-a9f3-22a5-3a4a-e61902269bdb@redhat.com \
--to=eblake@redhat.com \
--cc=andrey.shinkevich@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=den@virtuozzo.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.