linux-kernel - Re: [PATCH 1/3] perf test: Support arch-specific shell tests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAP-5=fXDaKueO9HE-Gr3Q7R6qm2EjwnL845nh7R2OU+DCfrhyA@mail.gmail.com>
Date: Thu, 22 May 2025 13:09:56 -0700
From: Ian Rogers <irogers@...gle.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Kan Liang <kan.liang@...ux.intel.com>, 
	Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 1/3] perf test: Support arch-specific shell tests

On Thu, May 22, 2025 at 10:10 AM Namhyung Kim <namhyung@...nel.org> wrote:
>
> This is a preparation for shell tests belong to an arch.

I keep repeating that I don't like arch and I think ideally we'd be
getting rid of the C arch tests. I just sent out a patch doing this
for 1 test:
https://lore.kernel.org/lkml/20250521165317.713463-2-irogers@google.com/
We should be able to make perf, tests, etc. dependent on a PMU rather
than an architecture. This means that running perf built for ARM will
be able to do things running on an instruction emulator on x86. It
means the tool, the kernel APIs, etc. are generic and new
architectures like RISC-V can test things. It means cross-platform
(record on 1 machine type, report on another) can work without
tripping over load bearing architecture ifdefs. It means that we
benefit from more testing on generic pieces of code on all
architectures - like sample parsing. We can always strcmp the PMU name
or the architecture at runtime.

Structure wise we could have:
tools/perf/pmu/ibs_op/tests/
tools/perf/pmu/ibs_op/tests/shell

It feels noisy compared to just having the shell test in
tools/perf/tests/shell skip when the PMU isn't present. There are also
things like library dependencies that aren't clear when we have >1
directory. I'd prefer if new testing followed the existing model
rather than this.

Thanks,
Ian