Received-SPF: pass (google.com: domain of linux-kernel+bounces-137035-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 9 Apr 2024 10:58:18 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>, Ian Rogers <irogers@google.com>,
	Kan Liang <kan.liang@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-perf-users@vger.kernel.org
Subject: Re: [PATCHSET 0/9] Sync tools headers with the kernel source
Message-ID: <ZhVJegoH7FKVtp0F@x1>
References: <20240408185520.1550865-1-namhyung@kernel.org>
 <ZhRB4BULj1Y1f1TN@x1>
 <ZhTw7e+sy0wfzgR5@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZhTw7e+sy0wfzgR5@gmail.com>

On Tue, Apr 09, 2024 at 09:40:29AM +0200, Ingo Molnar wrote:
> 
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > On Mon, Apr 08, 2024 at 11:55:11AM -0700, Namhyung Kim wrote:
> > > Hello,
> > > 
> > > I'm gonna carry these changes on the perf tools tree.  I'll update the
> > > vhost.h once it lands on the mainline.
> > 
> > Humm, maybe its not a good idea to do that this cycle?
> 
> Maybe it's just me, but I've been looking sadly at all the header warnings 
> for months. :-) Would be better to keep them in sync with a bit higher 

I backtracked from asking for a delay, the reason for me first thinking
about not doing it this time is because in perf-tools-next we have, to
be merged for 6.10:

⬢[acme@toolbox perf-tools-next]$ git log --oneline torvalds/master.. | tail
f324b73c2c05832b perf beauty: Stop using the copy of uapi/linux/prctl.h
c8bfe3fad4f86a02 perf beauty: Move arch/x86/include/asm/irq_vectors.h copy out of the directory used to build perf
7050e33e86ad03d2 perf beauty: Move uapi/sound/asound.h copy out of the directory used to build perf
44512bd6136ec7bb perf beauty: Move uapi/linux/usbdevice_fs.h copy out of the directory used to build perf
ab3316119f9d0b3a perf beauty: Move uapi/linux/mount.h copy out of the directory used to build perf
22916d2cbad9a20d perf beauty: Don't include uapi/linux/mount.h, use sys/mount.h instead
faf7217a397f041f perf beauty: Move uapi/linux/fs.h copy out of the directory used to build perf
5d8c646038f2f173 perf beauty: Fix dependency of tables using uapi/linux/mount.h
4b3761eebb1c5c1b perf c2c: Fix a punctuation
a9f4c6c999008c92 perf trace: Collect sys_nanosleep first argument
⬢[acme@toolbox perf-tools-next]$

The reasoning for these changes is in the csets, for instance:

⬢[acme@toolbox perf-tools-next]$ git show 7050e33e86ad03d2 | head -21
commit 7050e33e86ad03d26d7b969bba1d48ee159be496
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Mar 11 17:07:33 2024 -0300

    perf beauty: Move uapi/sound/asound.h copy out of the directory used to build perf
    
    It is used only to generate string tables, not to build perf, so move it
    to the tools/perf/trace/beauty/include/ hierarchy, that is used just for
    scraping.
    
    This is a something that should've have happened, as happened with the
    linux/socket.h scraper, do it now as Ian suggested while doing an
    audit/refactor session in the headers used by perf.
    
    Suggested-by: Ian Rogers <irogers@google.com>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/lkml/CAP-5=fWZVrpRufO4w-S4EcSi9STXcTAN2ERLwTSN7yrSSA-otQ@mail.gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
⬢[acme@toolbox perf-tools-next]$

I.e. I had moved some of the stuff that is being updated, but nah,
better to have v6.9 tools/perf building without warnings, I'll fixup the
merge when I merge perf-tools-next with torvalds/master after the
updates are merged upstream.

This is sometimes difficult to achieve tho or would require more pull
requests to be sent to Linus to get some last minute changes, its not
something common, but I think happened a few times.

> frequency, IMO - which would reduce the pain and churn rate:
> 
> > >  16 files changed, 809 insertions(+), 740 deletions(-)
> 
> That's like about a year of changes missed? An update once per cycle and 
> this wouldn't be nearly as painful, right?

Humm, I haven't checked if it stays that long without merging, what I've
agreed with Namhyung is to wait a bit for things to reach upstream, say
-rc3, and then do the update, trying not to do these things nor early
not late in the -rc sequence, to pick a sweet spot where most likely no
changes will be made, we make the update and the perf build has no
warnings in the final release.

- Arnaldo