Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch

[Ian Rogers]

On Tue, Mar 24, 2026 at 9:32 AM Arnaldo Melo <arnaldo.melo@xxxxxxxxx> wrote:
>
>
>
> On March 24, 2026 1:17:18 PM GMT-03:00, Arnaldo Melo <arnaldo.melo@xxxxxxxxx> wrote:
> >
> >
> >On March 24, 2026 1:12:08 PM GMT-03:00, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >>On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> >>>
> >>>       tools arch x86: Sync the msr-index.h copy with the kernel sources
> >>>       tools headers UAPI: Sync linux/kvm.h with the kernel sources
> >>>       tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources
> >>>       tools headers: Synchronize linux/build_bug.h with the kernel sources
> >>
> >>So I think we need to come up with some solution to *not* do this all,
> >>because honestly, it's getting hugely annoying.
> >>
> >>And it's not annoying due to the unnecessary diffs per se, but because
> >>this tool header sync then causes 'objtool' - which also uses some of
> >>those headers - to be rebuilt, and then that causes *everything* to be
> >>rebuilt.
> >>
> >>Just because the perf tree decided it needed to sync headers for
> >>unexplained reasons.
> >>
> >>The docs say "this works surprisingly well". That *used* to be the
> >>case. But with objtool also being affected, it really does *not* work
> >>well at all.
> >>
> >>And no, the tools cannot use the kernel headers directly. That
> >>*really* didn't work well, and required synchronizing kernel changes
> >>with tooling changes, and was just a pain.
> >>
> >>So the "header copies" solved a real problem, but we need to figure
> >>out something better.
> >>
> >>And honestly, the "something better" may be to just remove the
> >>mindless check for "headers aren't 100% sync".
> >>
> >>Because 99% of the time nobody cares. This time, for example, the
> >>header changes in question were comments and stuff that was inside a
> >>__KERNEL__ guard.
> >>
> >>So how about just at least as a first step trying to remove the
> >>warning that is actively detrimental, and only do header syncs when
> >>there is a *real* reason for them?
> >
> >Yeah, I agree, annoying, I'll work on making this opt-in, i.e. no warnings by default, a new target to check if drift happened.
>
> Also maybe this is something for Sashiko or some other AI agent, to automate/suggest/do the sync when it makes sense and not just out of making it is in sync no matter what.

Progress was made as the beauty files moved from tools/include into
tools/perf/trace/beauty. The recompilation should only really happen
if objtool uses a header via tools/include and the entire process
being out-of-sync and needing to rebuild seems to be working as
intended. The sashiko reviews tend to be more demanding in this
regard.

I'd like to see tools/include removed, especially as tools projects
tend to put " -I$(top_srcdir)/tools/include
-I$(top_srcdir)/tools/uapi/include" which prioritizes the kernel over
the UAPI headers. I think this is the opposite of what is expected in
user space. My ideal would be to have things like linux/list.h become
library projects in tools and you "make install_headers" on them, then
have the -I pick up the installed headers path like we do for libbpf,
etc.;
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.perf?h=perf-tools-next&id=c5a244bf17caf2de22f9e100832b75f72b31d3e6#n363
I think this would be cleaner but wouldn't remove the need to keep
things in sync and rebuilding.

Thanks,
Ian

> - Arnaldo
>
> Sry, the previous reply didn't make it to lkml :-/
>