On Mon Dec 29, 2025 at 5:17 PM CET, Steven Rostedt wrote: > It will waste a lot of kernel developers time. Go to conferences and talk > with developers. trace_printk() is now one of the most common ways to debug > your code. Having to add "#include <linux/trace_printk.h>" in every file > that you use trace_printk() (and after your build fails because you forgot > to include that file **WILL** slow down kernel debugging for hundreds of > developers! It *is* used more than printk() for debugging today. Because > it's fast and can be used in any context (NMI, interrupt handlers, etc).
I strongly agree with this. I heavly use trace_printk() for debugging for a long time and have recommended it to dozens of people that all have been very thankful for it -- especially when it comes to debugging race conditions on a tough timing, where a normal printk() simply "fixes" the race. Having to include additional headers would be very painful, especially when debugging large code bases with lots of files. For instance, one of the components I maintain is the nouveau driver with 773 C files and 1390 files overall. I suppose it would be fair to argue that such codebases usually have their own common header files that could be reused, but even in that case, I’d consider the ergonomic cost too high. - Danilo
