Re: [PATCHSET 0/9] Sync tools headers with the kernel source

[Namhyung Kim <namhyung@kernel.org>]

Hi Arnaldo and Ingo,

On Tue, Apr 9, 2024 at 6:58 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> 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.

Yeah I noticed that, but I thought it's better to keep v6.9 headers in
sync.  Please take care of them in perf-tools-next for v6.10.

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

I think we're doing it once per release cycle already.  This is just for v6.9.
The kvm changes moved some code to arch directories.

This is what I did for v6.7.

https://lore.kernel.org/r/20231121225650.390246-1-namhyung@kernel.org/

Thanks,
Namhyung