When skipping duplicated lines, the end of the log can just be a
star ("*") which may be confusing (?), so in order to clarify the end of
the log, tell the user how many lines where skipped and mimic the
userspace hexdump output, let's add in this case a new line with the
next offset.

With the following data:

00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

When skipping identical lines we were seeing:

00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
*

And now we will have:

00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
*
00000080

However if the output was (first bit of first byte on last line changed):

00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
00000070: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
           ^

When skipping identical lines we would see:

00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
*
00000070: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................

And in this case the output would not change with this patch.

Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
This change is not related to the two first patches and is just an
addition that was requested by Andy who felt like it was not clear where
the dump was ending with the 'SKIP_DUPLICATE' flag when the last line
was skipped. Honestly this never bothered me, so depending on the
maintainers wishes, this can either be applied or skipped.
---
 lib/hexdump.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lib/hexdump.c b/lib/hexdump.c
index f0d1a7f1ce817fd53a7ffd259fbe9b9c8348db16..c0c9a13838513bc7dec2ebdeadf622cd319ea4f8 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -302,6 +302,13 @@ void print_hex(const char *level, const char *prefix_str, int rowsize, int group
 		else
 			printk("%s%s%s\n", level, prefix_str, linebuf);
 	}
+
+	if (same_line) {
+		if (dump_flags & DUMP_PREFIX_ADDRESS)
+			printk("%s%s%p\n", level, prefix_str, ptr + i);
+		else if (dump_flags & DUMP_PREFIX_OFFSET)
+			printk("%s%s%.8x\n", level, prefix_str, i);
+	}
 }
 EXPORT_SYMBOL(print_hex);
 

-- 
2.48.1

On Wed, Mar 19, 2025 at 05:08:12PM +0100, Miquel Raynal wrote:
> When skipping duplicated lines, the end of the log can just be a
> star ("*") which may be confusing (?), so in order to clarify the end of
> the log, tell the user how many lines where skipped and mimic the
> userspace hexdump output, let's add in this case a new line with the
> next offset.
> 
> With the following data:
> 
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 
> When skipping identical lines we were seeing:
> 
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> *
> 
> And now we will have:
> 
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> *
> 00000080
> 
> However if the output was (first bit of first byte on last line changed):
> 
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 00000070: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
>            ^
> 
> When skipping identical lines we would see:
> 
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> *
> 00000070: fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> 
> And in this case the output would not change with this patch.

Thanks!

LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

...

> This change is not related to the two first patches and is just an
> addition that was requested by Andy who felt like it was not clear where
> the dump was ending with the 'SKIP_DUPLICATE' flag when the last line
> was skipped. Honestly this never bothered me, so depending on the
> maintainers wishes, this can either be applied or skipped.

I was also referring to userpsace `hexdump` behaviour. And I find it logical.

-- 
With Best Regards,
Andy Shevchenko