Re: [PATCH v3 0/3] hexdump: Allow skipping identical lines

[Petr Mladek <pmladek@suse.com>]

On Tue 2026-10-13 22:22:58, Andy Shevchenko wrote:
> +Cc: KUnit maintainers + Kees
> 
> On Wed, Mar 19, 2025 at 05:08:09PM +0100, Miquel Raynal wrote:
> > While working on NAND issues, I used print_hex_dump() a lot to compare
> > data. But I am mostly working on embedded systems where the kernel
> > messages go through a serial console. Sometimes network support is an
> > option, sometimes not. Anyway, I often print buffers both in kernel
> > space and user space to compare them, and they may be full of 0's or
> > 1's, which means lines are repeated a lot in the output and this is slow
> > *and* hard to compare.
> > 
> > I initially hacked into lib/hexdump.c for my own purpose and just
> > discarded all the other users, but it felt like this might be a useful
> > feature for others and decided to make it a public patch.
> > 
> > * First patch creates a helper named print_hex() with a prototype
> >   containing a flags parameter, instead of an entry for the prefix type
> >   and another entry for the ascii boolean. print_hex_dump() now
> >   falls back to print_hex().
> > * Second patch adds a new flag to possibly skip the identical lines.
> > * Third patch is optional, and adds the offset at which the dump
> >   finishes in case the last line to be printed would be skipped.
> > 
> > The Cc-list, as provided by get_maintainers.pl, was returning 330
> > e-mail addresses which felt to much, so I ran the script only on the
> > second patch (the printk/includes/debug/Doc changes). It gave this
> > Cc-list which sounds more reasonable. Hopefully this is a smart move,
> > otherwise let me know what you think would be best.
> 
> Sorry for the so late response. First of all, a bit of a background
> development on my side. At some point a few months ago I asked John
> Ogness to give me a private dive to the printk() guts. He explained
> to me a lot about ow printk() circular buffer works and that the
> implementation is nowadays done in the terms of circular buffer library
> and printk() front-end. This gives a potential to get a clean solution
> for the testing how printk() actually behaves.

I am curious what printk() features you would like to test.

> The main issue with the
> real printk() is that the buffer it's using is defined globally and
> for clean test cases the printk() can't be used. We discussed the way
> of high-jacking that by linking an object file of printk() implementation
> to the KUnit test, but it seems quite a tricky if ever achievable exercise.
> 
> Meanwhile Kees Cook seems found a nice workaround for the similar use case
> in his recent patch series [1]. The idea is to register custom console and
> provide a custom .write() method which is the heart of the solution. On
> the writer side user prints something which has unique prefix, while the
> console callback recognises that pattern and checks the rest of the line.

I ask because the solution used by Kees seems to be quite complicated
and unreliable for the given purpose. In particular, printk() does
only the best effort to flush messages on legacy consoles. And NBCON
consoles drivers are even offloaded to a kthread by default as
pointed out by John in the other mail.

It seems that Kees just want to check some particular printk() calls
and what messages they print. It might be easier and more reliable
to redirect printk() to an alternative implementation via a hook
in vprintk() in kernel/printk/printk_safe.c.

The vprintk() function used to redirect printk() by context,
e.g for recursive messages or NMI. It is much easier with the lockless
ringbuffer now. But it still does a redirection for kdb_printf().

I could even imagine that it could call vprintk_emit() with some
special facility which would cause redirecting the messages to
an alternative ring_buffer. Or we could even add a parameter
for this.

Anyway, the console machinery is pretty complex and just a best
effort. It would be better to avoid it unless you really want
to test the full printk() machinery.

Best Regards,
Petr