From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Joe Perches <joe@perches.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] lib/vsprintf: refactor duplicate code to xnumber()
Date: Mon, 28 Dec 2015 22:42:02 +0100 [thread overview]
Message-ID: <87h9j245ed.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <1451327112.3219.14.camel@perches.com> (Joe Perches's message of "Mon, 28 Dec 2015 10:25:12 -0800")
On Mon, Dec 28 2015, Joe Perches <joe@perches.com> wrote:
> On Mon, 2015-12-28 at 20:18 +0200, Andy Shevchenko wrote:
>> xnumber() is a special helper to print a fixed size type in a hex format with
>> '0x' prefix with padding and reduced size. In the module we have already
>> several copies of such code. Consolidate them under xnumber() helper.
>>
>> There are couple of differences though.
>>
>> It seems nobody cared about the output in case of CONFIG_KALLSYMS=n when
>> printing symbol address because the asked width is not enough to care either
>> prefix or last byte. Fixed here.
ok, though I'm curious what 'last byte' refers to here?
>> The %pNF specifier used to be allowed with a specific field width, though there
>> is neither any user of it nor mention in the documentation.
>>
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> ---
>> lib/vsprintf.c | 43 +++++++++++++++----------------------------
>> 1 file changed, 15 insertions(+), 28 deletions(-)
>>
>> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
>> index dcf5646..e971549 100644
>> --- a/lib/vsprintf.c
>> +++ b/lib/vsprintf.c
>> @@ -514,6 +514,16 @@ char *number(char *buf, char *end, unsigned long long num,
>> return buf;
>> }
>>
>> +static noinline_for_stack
>> +char *xnumber(char *buf, char *end, unsigned long long value, unsigned int type,
>> + struct printf_spec spec)
Is there any aspect of the passed-through printf_spec which isn't
overridden in xnumber? The users are/will be various %p extensions,
which probably means that no-one passes a non-default precision (gcc
complains about %.*p), and the remaining possible flags (PLUS, LEFT,
SPACE) are useless and/or impossible to pass to %p without gcc
complaining. In other words, why pass the spec at all instead of just
building it inside xnumber?
> xnumber isn't a great name.
Maybe 'hexnumber'. That's a bit further away from 'number', and 'x'
might stand for something other than hex.
> unsigned int type should probably be size_t size
Compromise: 'unsigned int size'. The name should be size since it's
supposed to be the size of the actual type being printed. But the type
carrying that information need not be 8 bytes wide on 64bits.
>> static noinline_for_stack
>> char *address_val(char *buf, char *end, const void *addr,
>> struct printf_spec spec, const char *fmt)
>> {
>> - unsigned long long num;
>> -
>> - spec.flags |= SPECIAL | SMALL | ZEROPAD;
>> - spec.base = 16;
>> -
>> switch (fmt[1]) {
>> case 'd':
>> - num = *(const dma_addr_t *)addr;
>> - spec.field_width = sizeof(dma_addr_t) * 2 + 2;
>> - break;
>> + return xnumber(buf, end, *(const dma_addr_t *)addr, sizeof(dma_addr_t), spec);
>> case 'p':
>> default:
>> - num = *(const phys_addr_t *)addr;
>> - spec.field_width = sizeof(phys_addr_t) * 2 + 2;
>> - break;
>> + return xnumber(buf, end, *(const phys_addr_t *)addr, sizeof(phys_addr_t), spec);
>> }
>> -
>> - return number(buf, end, num, spec);
>> }
Nit: I think it would be a bit easier to read if the cast+dereference
are kept outside the function calls. I'd suggest just introducing
'unsigned int size', assign the appropriate value in the two cases, and
fall through to a common 'xnumber(buf, end, num, size);'. It'll even
line up nicely ;-)
num = *(const dma_addr_t *)addr;
size = sizeof(dma_addr_t);
Rasmus
next prev parent reply other threads:[~2015-12-28 21:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-28 18:18 [PATCH v1 1/1] lib/vsprintf: refactor duplicate code to xnumber() Andy Shevchenko
2015-12-28 18:25 ` Joe Perches
2015-12-28 19:02 ` Andy Shevchenko
2015-12-29 0:18 ` Joe Perches
2015-12-28 21:42 ` Rasmus Villemoes [this message]
2015-12-28 22:20 ` Andy Shevchenko
2015-12-28 23:01 ` Rasmus Villemoes
2015-12-29 15:07 ` Andy Shevchenko
2015-12-28 22:20 ` Rasmus Villemoes
2015-12-28 22:29 ` Andy Shevchenko
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=87h9j245ed.fsf@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
/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.