[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aW_PXct-oIyOyrNe@x1>
Date: Tue, 20 Jan 2026 15:54:21 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: James Clark <james.clark@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] perf jevents: Handle deleted JSONS in out of source
builds
On Tue, Jan 20, 2026 at 10:01:52AM -0800, Ian Rogers wrote:
> On Tue, Jan 20, 2026 at 7:39 AM James Clark <james.clark@...aro.org> wrote:
> >
> > The cp command here doesn't remove files that have been removed from the
> > sourcetree. That means incremental builds can either succeed with stale
> > events or will fail completely if a stale json file has a broken
> > reference in it.
> >
> > Fix it by using rsync instead of cp. legacy-cache.json has to be
> > excluded as this is a generated file isn't present in the source tree.
> >
> > This only happens when deleting a JSON file, which has only happened
> > once since the linked commit. The fixes commit is marked as the origin
> > of the problem in case any future changes that delete JSONs are back
> > ported, rather than the first commit that deleted a JSON file.
> >
> > Reported-by: Mark Brown <broonie@...nel.org>
> > Closes: https://lore.kernel.org/linux-next/aW5XSAo88_LBPSYI@sirena.org.uk/
> > Fixes: 4bb55de4ff03 ("perf jevents: Support copying the source json files to OUTPUT")
> > Signed-off-by: James Clark <james.clark@...aro.org>
> > ---
> > This is a bit of a hack and I thought that making jevents.py handle
> > multiple input folders would be a much better solution than this. Then
> > we could have "gen-pmu-events" for only generated files and "pmu-events"
> > for only in-tree input files. It would be very clear what's generated
> > and what's not and all copying rules and special clean rules just
> > disappear (and this isn't the first time these rules have caused build
> > issues).
> >
> > Unfortunately, after a while of trying to modify the script I thought it
> > was too invasive for now. The script does output per-file at the very
> > bottom of the logic in process_one_file(), so adding files in another
> > folder ends up re-emitting section headers when another chunk is output.
> > Although other parts of the script do build things up in memory before
> > outputting so it was possible to make those parts work with multiple
> > folders transparently.
>
> Thanks James!
> Acked-by: Ian Rogers <irogers@...gle.com>
> I see other rsync uses in:
> tools/testing/selftests/sparc64/Makefile
> tools/testing/selftests/bpf/Makefile
> but they aren't the most compelling mainstream uses. I wonder whether
> we can test for rsync's availability and if not fall back on cp?
It is not mentioned at all in Documentation, so probably its best not to
add a requirement for it?
- Arnaldo
Powered by blists - more mailing lists