linux-kernel - Re: [PATCH 0/2] perf python: Add an example for sampling

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: <aMrk03gigBlGcYLK@x1>
Date: Wed, 17 Sep 2025 13:41:55 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Gautam Menghani <gautam@...ux.ibm.com>, peterz@...radead.org,
	mingo@...hat.com, namhyung@...nel.org, mark.rutland@....com,
	alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
	adrian.hunter@...el.com, kan.liang@...ux.intel.com,
	maddy@...ux.ibm.com, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] perf python: Add an example for sampling

On Wed, Sep 17, 2025 at 08:29:24AM -0700, Ian Rogers wrote:
> On Wed, Sep 17, 2025 at 5:37 AM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > And make:

> > perf script rwtop

> > Just call 'python PATH_TO_PYTHON_SCRIPTS/rwtop.py' transparently?
 
> Yeah, that's it. The perf script libpython stuff is just providing
> trace_begin, process_event and trace_end. Using the sampling
> mechanism, as shown in Gautum's patches, it is pretty easy to migrate
> them to being stand alone bits of python.
 
> > That looks interesting indeed, that way we would stop linking with
> > libpython, etc.

> > I wonder if there are out of tree scripts using the current tools/perf/util/scripting-engines/trace-event-python.c
> > mechanism...

> > But even that can fallback to a python based mechanism, right?

> I think so. Like I said about the use of a Dict for process_event, we
> may want to streamline things so there is a tension with what the API
> should be and compatibility. We can always have 2 APIs and try to
> deprecate one of them.

> > Import the script, if it has a given structure, use the new way, if not,
> > call a glue that reads the events and feed to the old style code.

> > Seems doable and would save code on the main perf binary and headaches
> > with the libpython and libperl build processes.

> So I see this for libpython, and I think it'd be pretty cool if we
> could have things work like this for say "perf script ilist" and

I think we could even try to, not having a builtin-ilist.c convert
'perf ilist' to 'perf script ilist' automagically.

> Alice's textual flamegraph work. I worry what the work for libperl
> would be like and whether it is worth it (hence sending the patch to
> at least start to make it opt-in rather than opt-out).

Maybe we should be a tad more cautious and start with emitting a warning
that "libperl is deprecated (holler if you disagree if you use it!)" and
then make it opt-in, and then remove it.

> Do you need my tags for these changes or wdyt about making the
> kwlist/API surface smaller?

Lemme look at the original post...

- Arnaldo