[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44upa7szd563kggh4xolznmfcwfnhrrh5guvecp6pzlvp5qvic@w7hxtzy7huzf>
Date: Mon, 12 Jan 2026 02:55:06 -0800
From: Breno Leitao <leitao@...ian.org>
To: John Ogness <john.ogness@...utronix.de>, pmladek@...e.com,
osandov@...ndov.com
Cc: Petr Mladek <pmladek@...e.com>, mpdesouza@...e.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org, asantostc@...il.com, efault@....de,
gustavold@...il.com, calvin@...nvd.org, jv@...sburgh.net, kernel-team@...a.com,
Simon Horman <horms@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, rostedt@...dmis.org
Subject: Re: [PATCH net-next 0/2] net: netconsole: convert to NBCON console
infrastructure
On Fri, Jan 09, 2026 at 04:19:31PM +0106, John Ogness wrote:
> On 2026-01-09, Petr Mladek <pmladek@...e.com> 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
> > 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/ [0]
Let me hack a new version of it with @comm, and post here to check how
it looks likes.
Powered by blists - more mailing lists