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

[John Ogness <john.ogness@linutronix.de>]

On 2026-10-13, Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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. 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.

The "sbufcap console" is using the legacy console interface. This is
probably good enough for now. However, we are currently working on
adding a "sync" feature to NBCON consoles. This feature would allow a
console to declare itself in "sync mode" and _every_ printk() call would
immediately and synchronously call into a ->write_atomic() console
callback. I think that feature would provide the level of printk
capturing that you want.

It also has the benefit of being useful outside of the KUnit testing
scope. (For example, pstore has also requested something similar.)

Until sync mode is ready, feel free to continue to use the less reliable
but probably good enough legacy console interface.

John Ogness

> [1]: https://lore.kernel.org/r/20261005155653.late.426-kees@kernel.org