From: Mark Brown <broonie@kernel.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] regmap: debugfs: improve regmap_reg_ranges_read_file()
Date: Tue, 29 Sep 2015 19:30:24 +0100 [thread overview]
Message-ID: <20150929183024.GC30445@sirena.org.uk> (raw)
In-Reply-To: <1443479342-31621-2-git-send-email-linux@rasmusvillemoes.dk>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On Tue, Sep 29, 2015 at 12:29:02AM +0200, Rasmus Villemoes wrote:
This patch is an example of why SubmittingPatches recommends splitting
things up into one change per patch, it would be much easier to read and
review as a series (especially given that there's very few collisions).
> * A page is a bit much for two integers and a bit of punctuation. 64
> bytes should suffice.
Right, the reason PAGE_SIZE was chosen is that it's a natural unit for
the allocator and is clearly absurdly large for the data. For 64 bytes
I have to think for a moment if it's suitably large. Please leave it at
PAGE_SIZE, it's not like this hangs around for any length of time.
> * Calling strlen() on entry no less than three times is silly,
> especially when snprintf() has returned that value (which was just
> thrown away).
I think we were expecting the compiler would figure out that strlen() is
a pure function and do the right thing here (though I do see it's
missing an annotation).
> * Transferring entry to the output buffer using snprintf is silly,
> when we know the length. Use memcpy instead.
Right, that's a legacy of a previous version transferring the maximum
amount of data possible (which got abandoned due to complexity).
However with the changes to use the return value of snprinf() it seems
like the best thing to do here is to go back to this and just fill up as
much of the buffer as we can by using snprintf() to do the transfer.
That said I think memcpy() is going to be the best way of getting to
that since one of the issues there (which currently doesn't work) is
slicing things off the front and memcpy() handles that nicely.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-09-29 18:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-28 22:29 [PATCH 1/2] regmap: debugfs: remove bogus check Rasmus Villemoes
2015-09-28 22:29 ` [PATCH 2/2] regmap: debugfs: improve regmap_reg_ranges_read_file() Rasmus Villemoes
2015-09-29 18:30 ` Mark Brown [this message]
2015-09-30 9:51 ` Rasmus Villemoes
2015-09-30 17:18 ` Mark Brown
2015-09-30 18:30 ` [PATCH v2 1/3] regmap: debugfs: use snprintf return value in regmap_reg_ranges_read_file() Rasmus Villemoes
2015-09-30 18:30 ` [PATCH v2 2/3] regmap: debugfs: use memcpy instead of snprintf Rasmus Villemoes
2015-09-30 18:30 ` [PATCH v2 3/3] regmap: debugfs: simplify regmap_reg_ranges_read_file() slightly Rasmus Villemoes
2015-09-29 18:14 ` [PATCH 1/2] regmap: debugfs: remove bogus check Mark Brown
2015-09-30 7:27 ` Rasmus Villemoes
2015-09-30 17:20 ` Mark Brown
2015-09-30 17:52 ` Rasmus Villemoes
2015-09-30 18:14 ` Mark Brown
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=20150929183024.GC30445@sirena.org.uk \
--to=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
/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
all inboxes | Powered by JetHome®