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

Hello Petr,

On Mon, Jan 19, 2026 at 03:00:11PM +0100, Petr Mladek wrote:

quoted

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

I see. Honestly, I never liked the way how dictionary was printed.
It used another syntax than loglevel, sequence id, and timestamp.
It might be confusing and complicate parsing.

But it is a personal opinion. Others might like it because
it might be easier for human eyes parsing.

IMHO, the information needs some parsing anyway to make it human readable:

  + people do not know the log level meaning out of head
  + message id is there primary to detect lost messages
  + timestamp needs conversion, definitely

Sigh, the use of lower case letters for "cpu" and "taskname" made it
even more inconsistent. I would voted against it if I did the review ;-)

Me too. ;-)

At least, we can use it to differentiate what is coming from pritnk
dictionary and netconsole.

quoted

Here is the full patch I was using to test the integration of netconsole and
the previous printk patch:

https://github.com/leitao/linux/commit/4175dc10719a15844b3a0bd7aa38158a913181a3

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.

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.

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?

Thanks
--breno