From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Denis Plotnikov" <dplotnikov@virtuozzo.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
"Max Reitz" <mreitz@redhat.com>
Subject: Re: ImageInfo oddities regarding compression
Date: Fri, 27 Nov 2020 16:25:34 +0100 [thread overview]
Message-ID: <20201127152534.GC4736@merkur.fritz.box> (raw)
In-Reply-To: <87ft4vq9c1.fsf@dusky.pond.sub.org>
Am 27.11.2020 um 13:21 hat Markus Armbruster geschrieben:
> >> I fell down this (thankfully shallow) rabbit hole because we also have
> >>
> >> { 'enum': 'MultiFDCompression',
> >> 'data': [ 'none', 'zlib',
> >> { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
> >>
> >> I wonder whether we could merge them into a common type.
>
> Looks like we could: current code would never report the additional
> value 'none'. Introspection would show it, though. Seems unlikely to
> cause trouble. Observation, not demand.
Forgot to comment on this one...
Technically we could probably, but would it make sense? Support for
compression formats has to be implemented separately for both cases, so
that they currently happen to support the same list is more of a
coincidence.
If we ever add a third compression format to qcow2, would we add the
same format to migration, too, or would we split the schema into two
types again?
Kevin
next prev parent reply other threads:[~2020-11-27 15:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 10:06 ImageInfo oddities regarding compression Markus Armbruster
2020-11-27 10:14 ` Daniel P. Berrangé
2020-11-27 10:32 ` Kevin Wolf
2020-11-27 12:21 ` Markus Armbruster
2020-11-27 15:25 ` Kevin Wolf [this message]
2020-11-27 16:52 ` Markus Armbruster
2020-11-30 17:36 ` Daniel P. Berrangé
2020-11-30 17:24 ` Eric Blake
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=20201127152534.GC4736@merkur.fritz.box \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dplotnikov@virtuozzo.com \
--cc=mreitz@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).