Do you mean the target of the symlink is also a symlink? No.
/sys/devices/system/cpu/events/event_source points
to /sys/devices/system/cpu/event_source.
/sys/devices/system/cpu/event_source/ is a sysfs dir, not a symlink.
Ingo's explanation looks much more clear.
<---snip start--->
We _really_ dont want to call it a 'PMU' but 'events coming from an event
source'.
The reason is that a PMU is an existing term that is quite attached to a CPU -
while many hardware events come not from a PMU. Interrupts, error conditions,
hotplug events, etc. etc.
Furthermore, the name 'PMU' is even less correct for software events.
So lets stick with 'events' and with some container that originates them.
(event_source) Ok?
<---snip end--->
For cpu hardware events(cycles, branch-misses, L1-dcache-loads etc...),
yes.
sysfs, "It provides a means to export kernel data structures, their
attributes, and the linkages between them to userspace."
pmus and events have attributes that userspace tool want to know, for
example, pmu id, event config value.
And they also have linkage, for example, cycles event uses cpu pmu to
handle it, so
/sys/devices/system/cpu/events/cycles/event_source
---> /sys/devices/system/cpu/event_source
No.
In userspace, open a sysfs file, see patch 11.
Then pass the open file's fd to the syscall sys_perf_event_open.
In kernel, use the passed in fd to find the pmu.
Not export it today.
Want to solve the problem of how to address an "event source".
I thought it's clear to export via sysfs, but, I maybe totally wrong...
Thanks,
Lin Ming
--
