mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Leizhen (ThunderTown)" <thunder.leizhen@huaweicloud.com>
To: Randy Dunlap <rdunlap@infradead.org>,
	Petr Mladek <pmladek@suse.com>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>,
	linux-kernel@vger.kernel.org
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Subject: Re: [PATCH 1/2] hexdump: minimize the output width of the offset
Date: Tue, 8 Aug 2023 09:10:05 +0800	[thread overview]
Message-ID: <8b7a579e-473d-ea90-58e0-e2f69f9bd002@huaweicloud.com> (raw)
In-Reply-To: <41713c95-51a8-8e2a-9c70-dab10dacf26d@infradead.org>



On 2023/8/8 6:37, Randy Dunlap wrote:
> Hi--
> 
> On 8/5/23 00:21, thunder.leizhen@huaweicloud.com wrote:
>> From: Zhen Lei <thunder.leizhen@huawei.com>
>>
>> The offset of case DUMP_PREFIX_OFFSET always starts from 0. Currently,
>> the output width is fixed to 8. But we usually dump only tens or hundreds
>> of bytes, occasionally thousands of bytes. Therefore, the output offset
>> value always has a number of leading zeros, which increases the number of
>> bytes printed and reduces readability. Let's minimize the output width of
>> the offset based on the number of significant bits of its maximum value.
>>
>> Before:
>> dump_size=36:
>> 00000000: c0 ba 8c 80 00 80 ff ff 6c 93 ee 2f ee bf ff ff
>> 00000010: 00 50 1e 98 ff 27 ff ff 01 00 00 00 00 00 00 00
>> 00000020: 80 ca 2f 98
>>
>> After:
>> dump_size=8:
>> 0: c0 ba 89 80 00 80 ff ff
>>
>> dump_size=36:
>> 00: c0 3a 91 80 00 80 ff ff 6c 93 ae 76 30 ce ff ff
>> 10: 00 60 cd 60 7d 4e ff ff 01 00 00 00 00 00 00 00
>> 20: 40 9e 29 40
>>
>> dump_size=300:
>> 000: c0 ba 8d 80 00 80 ff ff 6c 93 ce d4 78 a7 ff ff
>> 010: 00 00 16 18 0c 40 ff ff 01 00 00 00 00 00 00 00
>> 020: 01 00 00 00 00 00 00 00 e8 bc 8d 80 00 80 ff ff
>> ... ...
>> 110: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 120: 00 08 12 01 0c 40 ff ff 00 00 01 00
>>
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>>  lib/hexdump.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/hexdump.c b/lib/hexdump.c
>> index 06833d404398d74..86cb4cc3eec485a 100644
>> --- a/lib/hexdump.c
>> +++ b/lib/hexdump.c
>> @@ -263,12 +263,21 @@ void print_hex_dump(const char *level, const char *prefix_str, int prefix_type,
>>  		    const void *buf, size_t len, bool ascii)
>>  {
>>  	const u8 *ptr = buf;
>> -	int i, linelen, remaining = len;
>> +	int i, linelen, width = 0, remaining = len;
>>  	unsigned char linebuf[32 * 3 + 2 + 32 + 1];
>>  
>>  	if (rowsize != 16 && rowsize != 32)
>>  		rowsize = 16;
>>  
>> +	if (prefix_type == DUMP_PREFIX_OFFSET) {
>> +		unsigned long tmp = len - 1;	/* offset start from 0, so minus 1 */
>> +
>> +		do {
>> +			width++;
>> +			tmp >>= 4;
>> +		} while (tmp);
>> +	}
>> +
> 
> You could put all of that ^^^ in the case DUMP_PREFIX_OFFSET below.

for (i = 0; i < len; i += rowsize) {

"case DUMP_PREFIX_OFFSET" is in the loop, and moving the code above
to the case DUMP_PREFIX_OFFSET will be calculate multiple times. But
following your prompt, I thought again, I can control it with the
local variable width. I will post v2 right away.

> Otherwise LGTM.
> 
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> Thanks.
> 
>>  	for (i = 0; i < len; i += rowsize) {
>>  		linelen = min(remaining, rowsize);
>>  		remaining -= rowsize;
>> @@ -282,7 +291,7 @@ void print_hex_dump(const char *level, const char *prefix_str, int prefix_type,
>>  			       level, prefix_str, ptr + i, linebuf);
>>  			break;
>>  		case DUMP_PREFIX_OFFSET:
>> -			printk("%s%s%.8x: %s\n", level, prefix_str, i, linebuf);
>> +			printk("%s%s%0*x: %s\n", level, prefix_str, width, i, linebuf);
>>  			break;
>>  		default:
>>  			printk("%s%s%s\n", level, prefix_str, linebuf);
> 

-- 
Regards,
  Zhen Lei


  reply	other threads:[~2023-08-08  1:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-05  7:21 [PATCH 0/2] hexdump: minimize the output width of address and offset thunder.leizhen
2023-08-05  7:21 ` [PATCH 1/2] hexdump: minimize the output width of the offset thunder.leizhen
2023-08-07 22:37   ` Randy Dunlap
2023-08-08  1:10     ` Leizhen (ThunderTown) [this message]
2023-08-08  2:42       ` Randy Dunlap
2023-08-08  2:54         ` Leizhen (ThunderTown)
2023-08-05  7:21 ` [PATCH 2/2] hexdump: add a new dump prefix DUMP_PREFIX_ADDRESS_LOW16 thunder.leizhen
2023-08-07 22:37   ` Randy Dunlap
2023-08-08  1:14   ` Steven Rostedt
2023-08-08  1:51     ` Leizhen (ThunderTown)
     [not found]       ` <319df959-5be9-66c5-680f-4a5ae59019b9@huaweicloud.com>
2023-08-09  4:10         ` Sergey Senozhatsky
2023-08-09  7:05           ` Leizhen (ThunderTown)
2023-08-11  7:31             ` Leizhen (ThunderTown)

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=8b7a579e-473d-ea90-58e0-e2f69f9bd002@huaweicloud.com \
    --to=thunder.leizhen@huaweicloud.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=thunder.leizhen@huawei.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

all inboxes | Powered by JetHome®