root@(none)$ pwd
/sys/bus/event_source/devices/smmuv3_pmcg_100020
root@(none)$ ls -l
total 0
-r--r--r-- 1 root root 4096 Feb 10 14:50 cpumask
drwxr-xr-x 2 root root 0 Feb 10 14:50 events
drwxr-xr-x 2 root root 0 Feb 10 14:50 format
-rw-r--r-- 1 root root 4096 Feb 10 14:50
perf_event_mux_interval_ms
drwxr-xr-x 2 root root 0 Feb 10 14:50 power
lrwxrwxrwx 1 root root 0 Feb 10 14:50 subsystem ->
../../bus/event_source
-r--r--r-- 1 root root 4096 Feb 10 14:50 type
-rw-r--r-- 1 root root 4096 Feb 10 14:50 uevent
Other PMU drivers which I have checked in drivers/perf also have the same.
Indeed I see no way to differentiate whether a PMU is an uncore or system.
So that is why I change the name to cover both. Maybe there is a better name
than the verbose pmu_is_uncore_or_sys().
I don't see the connection here with the sysid or '_sys' checking,So the connection is that in perf_pmu__find_map(), for a given PMU, the
that's just telling which ID to use when looking for an alias, no?
matching is now extended from only core or uncore PMUs to also these system
PMUs. And I use the sysid to find an aliasing table for any system PMUs
present.