Re: [PATCH v1 1/3] perf ilist: Don't display deprecated events

[Namhyung Kim]

On Sun, Oct 19, 2025 at 04:04:17PM -0700, Ian Rogers wrote:
> On Sat, Oct 18, 2025 at 11:50 PM Howard Chu <howardchu95@xxxxxxxxx> wrote:
> >
> > Hi Namhyung,
> >
> > On Sat, Oct 18, 2025 at 7:56 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> > >
> > > Hi Ian,
> > >
> > > On Thu, Oct 16, 2025 at 03:22:26PM -0700, Ian Rogers wrote:
> > > > Unsupported legacy events are flagged as deprecated. Don't display
> > > > these events in ilist as they won't open and there are over 1,000
> > > > legacy cache events.
> > >
> > > Off-topic, any chance to integrate this into a perf command?
> > > It'd be convenient if we can call this like `perf list --interactive`
> > > or some other way.
> >
> > You have my vote, user-friendliness is important.
> > I think Ian mentioned that the major drawback is the difficulty of
> > forwarding arguments passed to the ilist.py program. A random thought:
> > perf is known for binding everything under a single command, but to
> > make scripting more flexible, perhaps some Bash scripts added to
> > .bashrc could be considered. After all, perf is fundamentally a
> > command-line tool.
> 
> Thanks Howard and Namhyung,
> 
> I think Arnaldo also raised this in the past.  My thought on how to do
> this is to build in to `perf script`:
> 
> 1) `perf script` currently uses libpython and then exposes a
> trace_start, trace_end and process_event method. When building the
> flamegraph work the only place that textual can run is in trace_end as
> it needs to run on the main python thread. This means we can't do
> incremental loading of data files while textual is showing the data as
> perf wants to be the main thread. So step 1 is to create a python
> version of the trace_start, trace_end and process_event callbacks. To
> do this something like the session API needs wrapping or writing in
> python. I'm not sure I'd keep the API the same as the C one. It'd be
> interesting to think of async file processing. It'd be nice to make
> the generation of strings.. in the event lazier. We could start with
> the existing API though, and then migrate to something more complex
> later.

Sounds like a long term plan.  I'm ok with the change but not sure how
soon it would happen.  I was suggesting a short term workaround if you
don't plan to work on this.  I thought we can exec ilist.py with proper
settings from `perf list`.  But it's up to you. :)

Thanks,
Namhyung

> 
> 2) Once we have a session like API in python we can convert the
> existing `perf script` commands to be standalone tools similar to
> ilist. So we can convert all the existing tools to be standalone.
> 
> 3) Once we have standalone versions of the `perf script` scripts then
> we can have `perf script` just exec the commands. The install step can
> install the scripts like it currently does and we can move ilist into
> the scripts location.
> 
> 4) Once we run python things as tools in their own right we can
> deprecate the libpython stuff, probably make it a build opt-in thing,
> etc. It seems hard to delete unused features, like libbfd, from the
> codebase. We did merge a patch deprecating libperl as a step in this
> direction.
> 
> Thanks,
> Ian