Re: [PATCH net-next 0/4] (no cover subject)

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 28 Nov 2025 06:20:45 -0800 Breno Leitao wrote:
> This patch series introduces a new configfs attribute that enables sending
> messages directly through netconsole without going through the kernel's logging
> infrastructure.
> 
> This feature allows users to send custom messages, alerts, or status updates
> directly to netconsole receivers by writing to
> /sys/kernel/config/netconsole/<target>/send_msg, without poluting kernel
> buffers, and sending msgs to the serial, which could be slow.
> 
> At Meta this is currently used in two cases right now (through printk by
> now):
> 
>   a) When a new workload enters or leave the machine.
>   b) From time to time, as a "ping" to make sure the netconsole/machine
>   is alive.
> 
> The implementation reuses the existing message transmission functions
> (send_msg_udp() and send_ext_msg_udp()) to handle both basic and extended
> message formats.
> 
> Regarding code organization, this version uses forward declarations for
> send_msg_udp() and send_ext_msg_udp() functions rather than relocating them
> within the file. While forward declarations do add a small amount of
> redundancy, they avoid the larger churn that would result from moving entire
> function definitions.

The two questions we need to address here are :
 - why is the message important in the off-host message stream but not
   important in local dmesg stream. You mention "serial, which could be
   slow" - we need more details here.
 - why do we need the kernel API, netcons is just a UDP message, which
   is easy enough to send from user space. A little bit more detail
   about the advantages would be good to have.
The 2nd point is trivial, the first one is what really gives me pause.
Why do we not care about the logs on host? If the serial is very slow
presumably it impacts a lot of things, certainly boot speed, so...
perhaps it should be configured to only log messages at a high level?