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?