Re: [PATCH RFC 0/2] netconsole: allow replaying the printk buffer on demand

[Breno Leitao <leitao@debian.org>]

On Tue, Oct 27, 2026 at 02:47:22PM +0100, Petr Mladek wrote:
> On Mon 2026-10-26 10:49:32, Breno Leitao wrote:
> > 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?

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