[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aVv946dXQfOifz5O@yury>
Date: Mon, 5 Jan 2026 13:07:31 -0500
From: Yury Norov <yury.norov@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Joel Fernandes <joelagnelf@...dia.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Christophe Leroy <chleroy@...nel.org>,
Randy Dunlap <rdunlap@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
David Laight <david.laight@...box.com>,
Petr Pavlu <petr.pavlu@...e.com>,
Andi Shyti <andi.shyti@...nel.org>,
Vivi Rodrigo <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tursulin@...ulin.net>,
Daniel Gomez <da.gomez@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
On Mon, Jan 05, 2026 at 08:02:39PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 05, 2026 at 11:39:02AM -0500, Steven Rostedt wrote:
> > On Sun, 4 Jan 2026 02:20:55 +0200
> > Andy Shevchenko <andriy.shevchenko@...ux.intel.com> 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.
+1
> 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.
Not sure we need v5 because the only change is dropping the last patch
in the series. But if you prefer - I can send v5.
Powered by blists - more mailing lists