From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78B3234CFC7 for ; Thu, 26 Mar 2026 23:05:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774566321; cv=none; b=iVB7PTOp2ROuGo/IcJ9jecW8fs9DRFXAoYHsyA2mqPiF5NybI1u8RTYm6sYAdBozrDbscul1mojbicRMttLH5xVypoAAoeP4tmj0FGku7sC6MrGjDIMqqCrYAHGsjCjWmRcFqdkMtaENCefes0P+uaBe0FUaZYyjrxraLeXQ0wQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774566321; c=relaxed/simple; bh=oM4v2kLk6u6Fk65CaL6+yLgObxltY2WJp6Mkw0Vseu8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HWhmdy9wG3ivOjrTpL77IOvzx4zEamGsXKEzXAFcXwqxiUf1lWyhxjHMv3reQNuALujsNbx5uVrAQIJOP05vLkrtPbcWbMCUoWf9nMPtJ06wJl5ykS+YzSYuIpS8f87+bizY2Ymis3bxUMXGJPvmaDalQ9ltApMZYLuIm4AXm0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rUeP67AT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rUeP67AT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B52DDC116C6; Thu, 26 Mar 2026 23:05:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774566320; bh=oM4v2kLk6u6Fk65CaL6+yLgObxltY2WJp6Mkw0Vseu8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rUeP67AT1trRN1GUwsLw44IhfSUXo8b80qpbU1+cy/nGTw5V5SUxiUJn5SxSl94yk jEuWaE4OhYXz+ZPF+yU/GVLdO+VAGTogOSKCNSYr+16JnX20TOWYclgQ6MbCXQnvY3 4wMB4kle6VR2EAxhS5Z85P3GjC9ODzwSPVU1uyn0orNKwlEm0xL61DrPHxlMbcWdgw VT3NkY9g76zWSepo4nQfTig3cafJP6pFNbwcyBGeFgPwJWMjEvFLvG1N/V7bRUNpdc qOa5dPqxSRL9g1Sjl3qPmWTG2mAKKVF5PThWNIDSEeMmlRgJ0sKF6zCFjguZqTAY4F OVZAdBi7iBKPw== Date: Thu, 26 Mar 2026 16:05:19 -0700 From: Namhyung Kim To: Ian Rogers Cc: Arnaldo Melo , Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] perf tools fixes for v7.0: 2nd batch Message-ID: References: <20260323105725.1882966-1-acme@kernel.org> <1DCCF693-8FF4-4567-B0BB-41F00B0B4606@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 24, 2026 at 11:00:33AM -0700, Ian Rogers wrote: > On Tue, Mar 24, 2026 at 9:32 AM Arnaldo Melo wrote: > > > > > > > > On March 24, 2026 1:17:18 PM GMT-03:00, Arnaldo Melo wrote: > > > > > > > > >On March 24, 2026 1:12:08 PM GMT-03:00, Linus Torvalds wrote: > > >>On Mon, 23 Mar 2026 at 03:57, Arnaldo Carvalho de Melo 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