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
next prev parent 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®