Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
Peter Zijlstra <[email protected]> Mon, 22 Jun 2026 10:34:40 +0200
| Newsgroups | gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.kernel,gmane.linux.documentation,gmane.linux.kbuild.devel,gmane.linux.ports.ppc64.devel,gmane.comp.video.dri.devel,gmane.linux.ports.arm.kernel,gmane.linux.drivers.rdma,gmane.linux.usb.general,gmane.comp.file-systems.ext4,gmane.linux.nfs,gmane.comp.emulators.kvm.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jun 21, 2026 at 05:34:30AM -0400, Steven Rostedt wrote: > There's been complaints about trace_printk() being defined in kernel.h as it > can increase the compilation time. As it is only used by some developers for > debugging purposes, it should not be in kernel.h causing lots of wasted CPU > cycles for those that do not ever care about it. > > Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do > use it can set and not have to always remember to add #include <linux/trace_printk.h> > to the files they add trace_printk() while debugging. It also means that > those that do not have that config set will not have to worry about wasted > CPU cycles as it is only include in the CFLAGS when the option is set, and > its completely ignored otherwise. Did you forget your C 101 class? If you use a function, you gotta include the relevant header. You don't see userspace saying: 'Hey, you know what, perhaps we should add stdio.h to every other header, just in case someone wants to printf()' either. I really don't understand your argument. Yes, maybe someone will forget and then either their editor (if they have a halfway modern setup with LSP enabled) or their build will complain, but so what? This is all trivial stuff, surely we have more pressing matters to concern outselves with?