On 7/5/23 12:08 PM, Yafang Shao wrote:
On Wed, Jul 5, 2023 at 4:47 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
On 6/28/23 1:53 PM, Yafang Shao wrote:
By introducing support for ->fill_link_info to the perf_event link, users
gain the ability to inspect it using `bpftool link show`. While the current
approach involves accessing this information via `bpftool perf show`,
consolidating link information for all link types in one place offers
greater convenience. Additionally, this patch extends support to the
generic perf event, which is not currently accommodated by
`bpftool perf show`. While only the perf type and config are exposed to
userspace, other attributes such as sample_period and sample_freq are
ignored. It's important to note that if kptr_restrict is not permitted, the
probed address will not be exposed, maintaining security measures.
A new enum bpf_perf_event_type is introduced to help the user understand
which struct is relevant.
Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx>
[...]
+enum bpf_perf_event_type {
+ BPF_PERF_EVENT_UNSPEC = 0,
+ BPF_PERF_EVENT_UPROBE = 1,
+ BPF_PERF_EVENT_URETPROBE = 2,
+ BPF_PERF_EVENT_KPROBE = 3,
+ BPF_PERF_EVENT_KRETPROBE = 4,
+ BPF_PERF_EVENT_TRACEPOINT = 5,
+ BPF_PERF_EVENT_EVENT = 6,
Why explicitly defining the values of the enum?
With these newly introduced enums, the user can easily identify what
kind of perf_event link it is
See also the discussion:
https://lore.kernel.org/bpf/CAEf4BzYEwCZ3J51pFnUfGykEAHtdLwB8Kxi0utvUTVvewz4UCg@xxxxxxxxxxxxxx/
No objections to that. I was more wondering why explicitly stating the
numbers here, but I presume it's for quick readability.. looks like in
some of the uapi enums we do it, in some others we don't; fair enough.
Thanks,
Daniel
