From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: vsementsov@virtuozzo.com, qemu-block@nongnu.org,
rjones@redhat.com,
"reviewer:Incompatible changes" <libvir-list@redhat.com>,
tao3.xu@intel.com, armbru@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH v2 4/4] utils: Deprecate inexact fractional suffix sizes
Date: Tue, 23 Feb 2021 17:20:55 +0000 [thread overview]
Message-ID: <YDU5d/Ug+Jes4jE0@redhat.com> (raw)
In-Reply-To: <20210211204438.1184395-5-eblake@redhat.com>
On Thu, Feb 11, 2021 at 02:44:38PM -0600, Eric Blake wrote:
> The value '1.1k' is inexact; 1126.4 bytes is not possible, so we
> happen to truncate it to 1126. Our use of fractional sizes is
> intended for convenience, but when a user specifies a fraction that is
> not a clean translation to binary, truncating/rounding behind their
> backs can cause confusion. Better is to deprecate inexact values,
> which still leaves '1.5k' as valid, but alerts the user to spell out
> their values as a precise byte number in cases where they are
> currently being rounded.
>
> Note that values like '0.1G' in the testsuite need adjustment as a
> result.
>
> 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>
>
> ---
>
> I'm not a fan of this patch, but am proposing it for discussion purposes.
Likewise. I'm *not* in favour of this patch.
Allowing some fractions but not other fractions forces the potential
user to figure out what the exact fraction is up front, at which point
they've lost the benefit of using fractions. If users actually care
about byte exact values then they already have the option to specify
those exactly. If they've instead chosen to use fractions then they
have implicitly decided they're ok with the potentially in-exact
answer.
IMHO the only question is whethe we should truncate or round, and
I dont really have a preference - either is fine as long as we
are intentionally picking one and documenting it.
> ---
> docs/system/deprecated.rst | 9 +++++++++
> tests/test-cutils.c | 6 +++---
> tests/test-keyval.c | 4 ++--
> tests/test-qemu-opts.c | 4 ++--
> util/cutils.c | 9 +++++++--
> 5 files changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index 113c2e933f1b..2c9cb849eec5 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -154,6 +154,15 @@ Input parameters that take a size value should only use a size suffix
> the value is hexadecimal. That is, '0x20M' is deprecated, and should
> be written either as '32M' or as '0x2000000'.
>
> +inexact sizes via scaled fractions (since 6.0)
> +''''''''''''''''''''''''''''''''''''''''''''''
> +
> +Input parameters that take a size value should only use a fractional
> +size (such as '1.5M') that will result in an exact byte value. The
> +use of inexact values (such as '1.1M') that require truncation or
> +rounding is deprecated, and you should instead consider writing your
> +unusual size in bytes (here, '1153433' or '1153434' as desired).
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2021-02-23 17:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 20:44 [PATCH v2 0/4] improve do_strtosz precision Eric Blake
2021-02-11 20:44 ` [PATCH v2 1/4] utils: Enhance testsuite for do_strtosz() Eric Blake
2021-02-23 17:07 ` Daniel P. Berrangé
2021-02-11 20:44 ` [PATCH v2 2/4] utils: Improve qemu_strtosz() to have 64 bits of precision Eric Blake
2021-02-23 17:13 ` Daniel P. Berrangé
2021-02-11 20:44 ` [PATCH v2 3/4] utils: Deprecate hex-with-suffix sizes Eric Blake
2021-02-11 22:59 ` Philippe Mathieu-Daudé
2021-02-23 17:13 ` Daniel P. Berrangé
2021-02-11 20:44 ` [PATCH v2 4/4] utils: Deprecate inexact fractional suffix sizes Eric Blake
2021-02-23 17:20 ` Daniel P. Berrangé [this message]
2021-02-24 13:52 ` Eric Blake
2021-02-22 20:19 ` [PATCH v2 0/4] improve do_strtosz precision 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=YDU5d/Ug+Jes4jE0@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=tao3.xu@intel.com \
--cc=vsementsov@virtuozzo.com \
/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).