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

[Namhyung Kim]

On Tue, Mar 24, 2026 at 11:00:33AM -0700, Ian Rogers wrote:
> 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.

Agreed.  Maybe we can limit the checker script to look up the beauty
directory only then.

> 
> 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.

Interesting.  It'd be great if we could get rid of any duplication.

Thanks,
Namhyung