public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox