Ah, I have sent it prematurely. On Thu 2025-12-04 11:46:21, Petr Mladek wrote: > On Tue 2025-12-02 10:24:42, Jakub Kicinski wrote: > > On Tue, 2 Dec 2025 02:18:44 -0800 Breno Leitao wrote: > > > On Mon, Dec 01, 2025 at 04:36:22PM -0800, Jakub Kicinski wrote: > > > > 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. > > > > > > > > This feature (in this patchset) is just one step ahead, giving some more > > > power to netconsole, where extra information could be sent beyond what > > > is in dmesg. > > > > Having extra metadata makes sense, since the interpretation happens in > > a different environment. But here we're talking about having extra > > messages, not extra metadata. > > > > > > 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... > > > > > > This is spot-on - slow serial definitely impacts things like boot speed. > > > > > > See my constant complains here, about slow boot > > > > > > https://lore.kernel.org/all/agvn%[email protected]/ > > > > > > And the something similar in reboot/kexec path: > > > > > > > > > https://lore.kernel.org/all/sqwajvt7utnt463tzxgwu2yctyn5m6bjwrslsnupfexeml6hkd@v6sqmpbu3vvu/ > > > > > > > perhaps it should be configured to only log messages at a high level? > > > > > > Chris is actually working on per-console log levels to solve exactly > > > this problem, so we could filter serial console messages while keeping > > > everything in other consoles (aka netconsole): > > > > > > https://lore.kernel.org/all/[email protected]/ > > > > Excellent! Unless I'm missing more context Chris does seem to be > > attacking the problem at a more suitable layer. > > This would help to bypass slow serial consoles. But the extra messages > would still get stored into the kernel ring buffer and passed back > to user space logs, for example journalctl.
It might actually make sense for the "workload enters or leaves" messages. But I am not sure about the "ping" messages. > I do not have strong opinion whether adding the > /sys/kernel/config/netconsole/<target>/send_msg is a good idea or not. I just wanted to point out that it is not only about slow serial consoles. Best Regards, Petr
