diff options
author | Eric Blake <eblake@redhat.com> | 2021-02-11 14:44:37 -0600 |
---|---|---|
committer | Eric Blake <eblake@redhat.com> | 2021-03-08 13:36:37 -0600 |
commit | f174cd3350c5e97db000e7383be974c66046b8f5 (patch) | |
tree | 01833a8fd59c747e40595918a2b82252b76ef734 /hw | |
parent | cf923b783efd565787e9ab006fb5608bb2a7297b (diff) | |
download | qemu-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 'hw')
0 files changed, 0 insertions, 0 deletions