aboutsummaryrefslogtreecommitdiff
path: root/block/blkreplay.c
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2021-02-11 14:44:37 -0600
committerEric Blake <eblake@redhat.com>2021-03-08 13:36:37 -0600
commitf174cd3350c5e97db000e7383be974c66046b8f5 (patch)
tree01833a8fd59c747e40595918a2b82252b76ef734 /block/blkreplay.c
parentcf923b783efd565787e9ab006fb5608bb2a7297b (diff)
downloadqemu-f174cd3350c5e97db000e7383be974c66046b8f5.zip
qemu-f174cd3350c5e97db000e7383be974c66046b8f5.tar.gz
qemu-f174cd3350c5e97db000e7383be974c66046b8f5.tar.bz2
utils: Deprecate hex-with-suffix sizes
Supporting '0x20M' looks odd, particularly since we have a 'B' suffix that is ambiguous for bytes, as well as a less-frequently-used 'E' suffix for extremely large exibytes. In practice, people using hex inputs are specifying values in bytes (and would have written 0x2000000, or possibly relied on default_suffix in the case of qemu_strtosz_MiB), and the use of scaling suffixes makes the most sense for inputs in decimal (where the user would write 32M). But rather than outright dropping support for hex-with-suffix, let's follow our deprecation policy. Sadly, since qemu_strtosz() does not have an Err** parameter, and plumbing that in would be a much larger task, we instead go with just directly emitting the deprecation warning to stderr. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20210211204438.1184395-4-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Diffstat (limited to 'block/blkreplay.c')
0 files changed, 0 insertions, 0 deletions