On Fri, Jan 09, 2026 at 04:19:31PM +0106, John Ogness wrote:

On 2026-01-09, Petr Mladek [off-list ref] wrote:

...

Crash/dump tools that are not updated would at least continue to print
the text at the beginning of the line. Here are a few projects that I
track and how they would react (unmodified):

makedumpfile
- https://github.com/makedumpfile/makedumpfile/blob/master/printk.c#L134
- will print "\x00" between the fields

vmcore-dmesg
- https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/util_lib/elf_info.c?h=main#n904
- will print "\x00" between the fields

crash
- https://github.com/crash-utility/crash/blob/master/printk.c#L210
- will print "." between the fields

drgn:

I know that drgn also parses it, and has a if depending the kernel
version (before or after commit commit 896fbe20b4e2 ("printk: use the
lockless ringbuffer")

https://github.com/osandov/drgn/blob/44ba3eb43a44f246fe3e65a728aa2594a19f15ee/drgn/helpers/linux/printk.py#L252C1-L255C55

quoted

My opinion:
===========

I personally think that the approach B) is the best compromise for now
because:

1. We really should distinguish task/interrupt context. IMHO, it is
   a very useful information provided by the caller_id now.

Agree. I don't have it in netconsole yet, but, this is I would like to
implement.

My ordered preferences for right now would be:

1. keeping @caller_id semantics + adding @cpu + adding @comm (similar to
your C)

This is similar the PoC I wrote earlier in this thread [0] plus @comm.

Link: https://lore.kernel.org/all/j764nuipx4nvemd3wlqfyx77lkdf7wgs5z452hlacwglvc2e7n@vsko4bq5xb2f/ (local) [0]

Let me hack a new version of it with @comm, and post here to check how
it looks likes.