From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@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 17:52:09 +0100 [thread overview]
Message-ID: <87eeken3nq.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20201127152534.GC4736@merkur.fritz.box> (Kevin Wolf's message of "Fri, 27 Nov 2020 16:25:34 +0100")
Kevin Wolf <kwolf@redhat.com> writes:
> 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?
I figure if a compression method is worth adding to one, it's probably
worth adding to the other.
Having two separate enums isn't too bad. A third has been proposed[*],
but I hope we can reuse migration's existing enum there.
[*] [PATCH 1/6] migration: Add multi-thread compress method
next prev parent reply other threads:[~2020-11-27 16:54 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
2020-11-27 16:52 ` Markus Armbruster [this message]
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=87eeken3nq.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dplotnikov@virtuozzo.com \
--cc=kwolf@redhat.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 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.