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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi,

On 14/10/2026 at 21:38:37 -07, Kees Cook <kees@kernel.org> wrote:

> On Wed, Oct 14, 2026 at 05:38:44PM +0200, Petr Mladek wrote:
>> 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.
>
> Yeah, I was just trying to "prove" that seq_buf_do_printk() actually
> put something onto the console (and to match up what was written and how
> truncation behaved). :P I'm open to adjusting this however it should be...

Just to redirect the discussion towards my initial goal, what I would
like to bring is a userspace-like hexdump output which allows to skip
identical lines. I am printing a lot of flash content. Empty flashes are
full of ones, I mostly do not care about them, yet, during
tracing/debugging they take ages to be printed at 115200 bauds. So I was
just proposing to skip identical lines (with a '*') like in userspace.

Following my proposal, Andy requested that I would add unit testing of
this outpout. At that time I refused it for two main reasons:
- it is mostly a debugging mechanism, so if it ever breaks or changes,
  it is not (IMHO) a big problem;
- there was no accessible testing infrastructure that would not be
  overly complex for verifying the output of those calls.

I am still convinced adding testing here is superfluous.

Andy and myself met during LPC in Prague. Andy claimed that we might now
have the relevant infrastructure to add the tests. If there is an easy
way, I will just do it and move on. But based on the recent exchanges,
that does not seem so obvious.

So, what is the appropriate move here?

Thanks,
Miquèl