On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote: > On Sun, 4 Jan 2026 02:20:55 +0200 > Andy Shevchenko <[email protected]> wrote: > > > > I do not think it is necessary to move it. > > > > I'm not talking about move, I'm talking about the C 101 thingy. Any custom > > API > > should be included before use, otherwise compiler won't see it. Which > > header do > > you want to include to have this API being provided? Note, it's really bad > > situation right now with the header to be included implicitly via > > non-obvious > > or obscure path. The discussion moved as far as I see it towards the > > finding a > > good place for the trace_printk.h. > > It's not a normal API. It's for debugging the kernel. Thus it should be > available everywhere without having to add a header. Hence, the best place > to include trace_printk.h, is in kernel.h.
With the above it sounds like you rather want to see it being included as kconfig.h (to every single file). But I disagree on that approach, why do we need this header to pollute every file even if I do not debug the thing? But since the current state is kernel.h, the status quo is to keep it there for now. > I'm thinking that my proposed config option is the best solution now. For > those that do not care about debugging the kernel, you enable the > "HIDE_TRACE_PRINTK" config so that your builds will be "quicker". But for > everyone else, it will not slow down their workflow when they need to debug > code. Maybe, to keep a status quo. Seems for now the compromise is to have it split and be included back to kernel.h and later we can decide if the option or other variants can give a better granularity for people who are not lazy to remember and add a header if they need to debug stuff. Yury, I think in v5 you need to drop this patch, otherwise we won't move further. -- With Best Regards, Andy Shevchenko
