Kevin Wolf <[email protected]> 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
