Re: [PATCH net-next 0/2] net: netconsole: convert to NBCON console infrastructure

[Petr Mladek <pmladek@suse.com>]

On Mon 2026-01-19 08:34:42, Breno Leitao wrote:
> Hello Petr,
> 
> On Mon, Jan 19, 2026 at 03:00:11PM +0100, Petr Mladek wrote:
> > > Context: netconsole outputs the message in a different way, similarly to the
> > > printk dictionary. I.e, taskname and cpu come after, one entry per line:
> > > 
> > >   <message>
> > >    SUBSYSTEM=net
> > >    DEVICE=+pci:0000:00:1f.6
> > >    cpu=42
> > >    taskname=NetworkManager
> > >    ...
> > 
> > BTW.1: I see that netconsole actually does not show pid. So that we do not
> >        need the trick with caller_id2. But people might want to add it in
> >        the future.
> 
> Correct, I haven't found the pid important when aggregating messages in
> the a fleet of hosts.

Good to know.

> > BTW.2: I also noticed that sysdata_append_msgid() uses netconsole-specific
> >        message counter.
> > 
> >        Note that each message has its own sequence number. It is the
> >        .seq member in struct printk_info. It is printed in the extended
> >        console output, see info_print_ext_header(). So it is printed
> >        even on netconsole when this extended format is used.
> > 
> >        I wonder if the netconsole-specific counter was added
> >        intentionally.
> 
> The addition was intentional. The purpose was to monitor the number of
> lost netconsole messages.
> 
> Originally we were using printk seq number to track "lost" message, later
> we discovered that some message numbers were never sent to netconsole
> , either due to  different loglevel or supressed message. Thus, using
> .seq was not useful to track lost netconsole message.
> 
> As a result, netconsole now increments the sequence number only when
> a packet is sent over the wire. Therefore, any gap in the "sequence"
> indicates that a packet was lost.

Makes perfect sense.

> Back o this current patch, I've tested it internally and run a test for
> hours without any current issue in terms of task->comm/cpu. 
> How would you prefer to proceed to get the patch in?

Is the netconsole part ready for mainline?

If yes, I would suggest to send the full patchset for review and
it might go in via the networking tree.

If no, then we could try to get in at least the printk part
for 6.20. I would personally use the variant with caller_id2
just to be on the safe side.

Note that AFAIK, there are no conflicting changes on the printk side
floating around.

Best Regards,
Petr