Re: perf-trace: improving ioctl details

[David Ahern]

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)

> 
>>
>>>
>>> 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*).

> 
>>
>> Great to see you contributing to perf again! 
> 
> +1
> 

Thanks. perf-trace code has changed quite a bit over the past 10 years.