From: David Disseldorp <ddiss@samba.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
David Laight <David.Laight@ACULAB.COM>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] lib/strtox: introduce kstrtoull_suffix() helper
Date: Wed, 27 Dec 2023 16:38:32 +1100 [thread overview]
Message-ID: <20231227163832.51e305f7@echidna> (raw)
In-Reply-To: <97b85612-16ab-4099-9a8e-426df510d7db@gmx.com>
On Sat, 23 Dec 2023 20:27:30 +1030, Qu Wenruo wrote:
> On 2023/12/20 16:08, David Disseldorp wrote:
...
> >> +#define KSTRTOULL_SUFFIX_DEFAULT (SUFFIX_K | SUFFIX_M | SUFFIX_G | SUFFIX_T | SUFFIX_P)
> >
> > I think it'd be clearer if you dropped this default and had callers
> > explicitly provide the desired suffix mask.
>
> Well, that would be long, and would be even longer as the newer naming
> would be MEMPARSE_SUFFIX_*, to be more explicit on what the suffix is for...
>
> And I really want callers to choose a saner default suffix, thus here
> comes the default one.
>
> In fact, in my next version, I also found that there are some memparse()
> call sites benefits from the newer suffixes (although won't for the "E"
> one).
> The example is the call site setup_elfcorehdr(). Where the comment only
> mentions KMG, but since memparse() silently added "PE" suffixes, maybe
> on some mainframes we saved some time for one or two lucky admins.
I think it's a sane default, my concern is that _DEFAULT says nothing
about supported units from the caller's perspective. Perhaps
MEMPARSE_SUFFIX_KMGTP or MEMPARSE_UNITS_KMGTP would be clearer.
...
> > With the above changes made, feel free to add
> > Reviewed-by: David Disseldorp <ddiss@suse.de>
>
> Thanks for the review, but I'm afraid the newer version would be another
> beast.
>
> All the ommitted comments would be addressed a in new series.
> >
> > I'll leave the review of patch 2/2 up to others, as I'm still a little
> > worried about sysfs trailing whitespace regressions.
>
> That won't be a problem anymore, the new series would keep the old
> @retptr behavior, thus for btrfs part it won't be changed at all.
Sounds good. Will follow up there.
Cheers, David
next prev parent reply other threads:[~2023-12-27 5:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 0:09 [PATCH v2 0/2] lib/kstrtox: introduce kstrtoull_suffix() helper Qu Wenruo
2023-12-20 0:10 ` [PATCH v2 1/2] lib/strtox: " Qu Wenruo
2023-12-20 5:38 ` David Disseldorp
2023-12-23 9:57 ` Qu Wenruo
2023-12-27 5:38 ` David Disseldorp [this message]
2023-12-20 14:17 ` Andy Shevchenko
2023-12-20 0:10 ` [PATCH v2 2/2] btrfs: sysfs: use kstrtoull_suffix() to replace memparse() Qu Wenruo
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=20231227163832.51e305f7@echidna \
--to=ddiss@samba.org \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.