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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Thu, Oct 15, 2026 at 10:43:26AM +0200, Miquel Raynal wrote:
> 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:
> >> > On Wed, Mar 19, 2025 at 05:08:09PM +0100, Miquel Raynal wrote:

...

> >> > 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.

Besides the case the Miquel has I was think more of the testing the front-end
part of printk(). The back-end, id est vsnprintf(), is well covered already
since we may control the buffer the vsnprintf() prints to. With real printk()
there is no control of the buffer, and as you explained below it might be
required to add some more hooks and code.

> >> > 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;

I find this feature is good in general and maybe actually part of the real ABI
or just beyond debugging.

> - 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.

Petr, also note, that this series doesn't use any modifications to the
hex_dump_to_buffer() facility as it's done on the upper layer of the printk()
that is not anyhow covered by unit tests. That's why I was insisting on the
test cases.

And since we want to cover lib/ with unit tests, I tend to try to fulfil that.
However, if there is a majority of stakeholders (Miquel, PRINTK() maintainers,
and reviewers) think otherwise we might do no tests exceptionally.

> 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?

Yep, we need some discussion here how to move forward. Again, I like
the feature, I just don't like it may go without testing.

-- 
With Best Regards,
Andy Shevchenko