Re: [PATCH RFC 0/2] netconsole: allow replaying the printk buffer on demand
flat view
From: Breno Leitao <leitao@debian.org>
Date: 2026-10-27 15:54:44
Also in:
linux-doc, lkml
On Tue, Oct 27, 2026 at 02:47:22PM +0100, Petr Mladek wrote:
On Mon 2026-10-26 10:49:32, Breno Leitao wrote:quoted
A bit of context on the use case from our side. In an ideal world netconsole is enabled from early boot through the kernel command line, but in some case this is impossible (linux as bootloaders - ipxe/sd-stubs/etc). The other way to setup netconsole is to create a new target at runtime through configfs. Netconsole then only sends messages from the time the target is enabled. For this second case, I would like to replay the whole kernel log on netconsole, such as previous messages. Something might have happened before the target was enabled, and we want visibility into that.Just to be sure that I understand it correctly. Is the netconsole registered before it gets functional, please?
Correct. The console is registered at module load time, in init_netconsole(), before any target is created. In other words, a single console is registered at module load, and the netconsole targets are then handled under that same console.
Is it possible to detect that the netconsole is not yet functional and when it could start working? I ask because there is the flag CON_PRINTBUFFER which should cause re-playing all messages on the console during registration. A solution might be to delay the console registration until the netwok target is really working.
Yes, we can register the console when the target is enabled. However, I
think the user will need to choose whether the console is registered
with CON_PRINTBUFFER or not, since in some cases they only want messages
from the moment the target is enabled.
So we would probably need one console per netconsole target?
Another solution might be to temporary block/disable the console until it gets operational. We already have console_suspend()/resume() API. But we might need something new to distinguish it from the system suspend/resume handling.
In that case, what happens to the console while it is suspended?
quoted
That said, the "per-console counter" might work as well, since it would start as 0, thus, we know that netconsole target would be behind, and try to replay? (not sure how yet)This is what the console_try_replay_all() does. The only difference is that it resets the counter to the oldest available message, see __console_rewind_all(). It is just a small optimization when the ring buffer is already full and the oldest messages are gone.
Right, but that would apply to all consoles, while in our case we only
want to replay the log on a specific console (netconsole).
Thanks for the suggestions,
--breno