Re: perf-trace: improving ioctl details

[Namhyung Kim]

On Fri, Feb 20, 2026 at 08:33:01AM -0700, David Ahern wrote:
> Sorry for the delayed response; my time seems to evaporate these days.

:)

> 
> On 2/19/26 11:49 AM, Namhyung Kim wrote:
> >>> Questions for you:
> >>> 1. is such an open ended design acceptable for perf-trace?
> >>
> >> Is it lazy, i.e. only when needed this cache/table gets loaded? 
> > 
> > I think it's ok.  But I'm curious what's the actual usecases.. do you
> > want it for testing kernels and drivers?  I guess we can have a default
> > table for regular users and provide the option for kernel developers.
> 
> The idea is that ioctl is a very open ended and overloaded uapi, and I
> wanted better granularity on how that time was spent. The breakdown by
> filename and NR is one level; improving human readability of the NR is
> another.
> 
> For the latter, if you look at tools/perf/trace/beauty/ioctl.c, you can
> see how human readability for NRs has been improved for specific
> subsystems tty, drm, pcm, kvm, ... (the table in ioctl__scnprintf_cmd),
> but that design is not going to scale for all of the devices and
> drivers, especially those with dynamic major numbers. Allowing runtime
> loading of files seemed like an easy way to accommodate the range of
> ioctl users in a flexible way. (though it too has limitations given the
> multiplexing on specific NRs)

I see.  So would your patch match ioctl by name instead of number?  I'm
curious if we can do the same in the beautifier code to handle dynamic
numbers.. maybe after checking static numbers.

> 
> > 
> >>
> >>>
> >>> 2. if yes, is there any preference on file format (json, yaml,
> >>> key-value, ...)?
> >>
> >> We already have JSON parsing infra, so probably that is better? 
> 
> json is used for the PMU files, but it seems to be used only for code
> generation (pmu-events/pmu-events.c) at build time, not run time loading
> which I was targeting. Hence the question on format.
> 
> > 
> > JSON should be fine, although it's a bit verbose.  I'm fine with plain
> > KEY=VALUE format too if it's really a simple mapping.
> 
> key=value format is what I have now. The only awkwardness is a header to
> declare the filename it corresponds to and then a further complication
> is the need for a wildcard format as there are examples that have
> multiple instances (e.g., /dev/infiniband/uverbs*).

I think it's ok as we have config files with this format:

  [section]
    # comment
    key = value

> 
> > 
> >>
> >> Great to see you contributing to perf again! 
> > 
> > +1
> > 
> 
> Thanks. perf-trace code has changed quite a bit over the past 10 years.
 
Yes, it does. :)

Thanks,
Namhyung