From: Eric Blake <eblake@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: vsementsov@virtuozzo.com, berrange@redhat.com,
qemu-block@nongnu.org, tao3.xu@intel.com, qemu-devel@nongnu.org,
armbru@redhat.com
Subject: Re: [PATCH 3/3] utils: Deprecate inexact fractional suffix sizes
Date: Fri, 5 Feb 2021 08:19:08 -0600 [thread overview]
Message-ID: <68bd33b1-8c79-0307-49c6-d4d38ab4b89c@redhat.com> (raw)
In-Reply-To: <20210205103446.GC30079@redhat.com>
On 2/5/21 4:34 AM, Richard W.M. Jones wrote:
> On Thu, Feb 04, 2021 at 01:07:08PM -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.
>>
>> Sadly, since qemu_strtosz() does not have an Err** parameter, we
>> pollute to stderr.
>
> Does "deprecate" mean there's a plan to eventually remove this? If so
> I think it should say that (in docs/system/deprecated.rst I think).
Yes (well, if we agree to the patch; Dan has already voiced concern that
we may not want 3/3 after all). And that's why I posted a followup
message mentioning that I failed to commit that docs/ change before
sending my v1. It will be in v2.
>
> I think it would be better to remove this now or in the future since
> it's a trap for users.
It's borderline - Markus has expressed a desire to remove inexact
fractions, while Dan has expressed the desire that user convenience is
important (as long as we are clear that non-fractional values are ALWAYS
exact, and that the use of a fraction is for convenience at which point
you KNOW you are risking rounding, then allowing both 1.1M and 1.5M
instead of only one of the two is nicer).
I submitted this patch because of IRC discussion, but if it is up to
just me, I'd keep 2/3 but drop 3/3 (that is, I'm happy to deprecate
0x4000M, but not happy to deprecate 0.1G, but rather merely posted the
patch to see what the fallout is because the question had been asked on
IRC).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2021-02-05 14:20 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 19:07 [PATCH 0/3] Improve do_strtosz precision Eric Blake
2021-02-04 19:07 ` [PATCH 1/3] utils: Improve qemu_strtosz() to have 64 bits of precision Eric Blake
2021-02-04 20:12 ` Eric Blake
2021-02-05 10:06 ` Vladimir Sementsov-Ogievskiy
2021-02-05 10:18 ` Vladimir Sementsov-Ogievskiy
2021-02-05 14:06 ` Eric Blake
2021-02-05 14:10 ` Daniel P. Berrangé
2021-02-05 10:07 ` Vladimir Sementsov-Ogievskiy
2021-02-05 14:12 ` Eric Blake
2021-02-05 10:28 ` Richard W.M. Jones
2021-02-05 14:15 ` Eric Blake
2021-02-05 11:02 ` Daniel P. Berrangé
2021-02-05 14:27 ` Eric Blake
2021-02-05 14:36 ` Daniel P. Berrangé
2021-02-05 11:34 ` Daniel P. Berrangé
2021-02-05 14:36 ` Eric Blake
2021-02-04 19:07 ` [PATCH 2/3] utils: Deprecate hex-with-suffix sizes Eric Blake
2021-02-05 10:25 ` Vladimir Sementsov-Ogievskiy
2021-02-05 10:31 ` Richard W.M. Jones
2021-02-05 13:38 ` Eric Blake
2021-02-05 11:13 ` Daniel P. Berrangé
2021-02-05 13:40 ` Eric Blake
2021-02-05 14:02 ` Daniel P. Berrangé
2021-02-04 19:07 ` [PATCH 3/3] utils: Deprecate inexact fractional suffix sizes Eric Blake
2021-02-04 20:02 ` Eric Blake
2021-02-05 10:34 ` Richard W.M. Jones
2021-02-05 14:19 ` Eric Blake [this message]
2021-02-05 10:38 ` Vladimir Sementsov-Ogievskiy
2021-02-05 11:10 ` Daniel P. Berrangé
2021-02-05 14:28 ` Eric Blake
2021-02-05 14:40 ` Daniel P. Berrangé
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=68bd33b1-8c79-0307-49c6-d4d38ab4b89c@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@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).