Re: [PATCH v1] samples/bpf: Add a trace tool with perf PMU counters

[Leo Yan]

On Mon, Jan 20, 2025 at 08:54:30PM +0100, Daniel Borkmann wrote:
> On 1/20/25 8:38 PM, Alexei Starovoitov wrote:
> > On Mon, Jan 20, 2025 at 10:50 AM Leo Yan <leo.yan@xxxxxxx> wrote:

[...]

> > > My understanding for bpftool is for eBPF program specific.  I looked
> > > into a bit the commit 47c09d6a9f67, it is nature for integrating the
> > > tracing feature for eBPF program specific.  My patch is for tracing
> > > normal userspace programs, I am not sure if this is really wanted by
> > > bpftool.  I would like to hear opinions from bpftool maintainer before
> > > proceeding.
> 
> Yes, that suggestion was if it would have been applicable also
> for the existing bpftool (BPF program) profiling functionality.
> 
> > > My program mainly uses eBPF attaching to uprobe.  selftest/bpf has
> > > contained the related functionality testing, actually I refered the
> > > test for writing my code :).  So maybe it is not quite useful for
> > > merging the code as a test?
> > > 
> > > If both options are not ideal, I would spend time to land the
> > > feature in perf tool - the perf tool has supported eBPF backend for
> > > reading PMU counters, but it is absent function based profiling.
> > 
> > We don't add tools to kernel repo. bpftool is an exception
> > because it's used during the selftest build.
> > 'perf' is another exception for historical reasons.
> > 
> > This particular feature fits 'perf' the best.
> 
> Agree, looks like perf is the best target for integration then.

Thanks for suggestions, Alexei and Daniel.  It makes sense for me to
move to perf, and now I understand the policy for moving code from
samples/bpf.

It may be irrelevant to the patch itself.  I know we have great BPF
toolings (BCC/bpftrace, etc), but it would be a bit confused for me
that we don't have a offical repo to maintain C based BPF toolkits.

Sometimes, C based BPF tool is small and handy ...

Thanks,
Leo