Re: [GIT PULL] tracing: Updates for 7.2

[Yury Norov <yury.norov@gmail.com>]

On Thu, Jun 18, 2026 at 09:23:04PM -0700, Linus Torvalds wrote:
> On Tue, 16 Jun 2026 at 15:01, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > tracing: Updates for v7.2:
> 
> I wondered why the heck this causes the whole kernel to be rebuilt,
> when the diffstat looked fairly innocuous.
> 
> It's because it changed <linux/trace_printk.h>, which used to be part
> of <linux/kernel.h> but was split out in commit bec261fec6d4
> ("tracing: move tracing declarations from kernel.h to a dedicated
> header").
> 
> But the second stage of splitting it out - not including it from
> <linux/kernel.h> - was never done, so now while the diffstat *looks*
> innocuous, it is still as deadly to the build as an actual
> <linux/kernel.h> change would be.
> 
> The intent was clearly to make people who actually needed the
> trace_printk() functionality to include the header - that's what the
> commit log says. But that's not how any of it works ;(
> 
> So all that commit did was to make things look like they wouldn't hurt
> as much as they do, and that trivial change to that file causes a full
> rebuild of the kernel.
> 
> I'm not seeing any patches even being discussed that would make only
> files that need it to include that file and remove it from
> linux/kernel.h that *everybody* uses. Yet that was the *only* point of
> making it a separate header in the first place. Yury?

Yes, you are right. The original intention was to decouple trace_printk()
and kernel.h, and I have the patch for it in v4:

https://lore.kernel.org/all/aVvoe5fQN3EUtEAJ@yury/

The Steven's point is the convenience for developers to throw
trace_printk() here and there without including any headers.

I'm not one of those trace_printk() users, but I take that. Even
though, I don't think it's a strong argument, pretty much for the
same reasons that you've described above.

I suggested adding a debugging flag, so that trace_printk() would
be included in kernel.h conditionally, if it's absolutely necessary
to have the API included "automatically":

> >         make D=1 // trace_printk() is available
> >         make D=0 // trace_printk() is not available
> >         make     // trace_printk() is not available

That was rejected too.

I even measured 1.5-2% compile time decrease back then. Surely need to
retest it to make sure.

I'm still for decoupling trace_printk() and kernel.h, so I can resend
if needed.

Thanks,
Yury