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
