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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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