Re: Future of BCC Python tools


Alexei Starovoitov
 

On Mon, Oct 26, 2020 at 3:34 PM Brendan Gregg <brendan.d.gregg@...> wrote:

G'Day all,

I have colleagues working on BCC Python tools (e.g., the recent
enhancement of tcpconnect.py) and I'm wondering, given libbpf tools,
what our advice should be.

- Should we keep both Python and libbpf tools in sync?
- Should we focus on libbpf only, and leave Python versions for legacy systems?
bcc python is still used by many where they need on the fly compilation.
Such cases still exist. One example is USDT support.
The libbpf and CO-RE support for USDT is still wip.
So such cases have to continue using bcc style with llvm.
The number of such cases is gradually reducing.
I think right now anyone who starts with bpf should be all set with
libbpf, BTF and CO-RE. It's much better suited for embedded setups too.
So I think bcc as a go-to place is still a great framework, but adding
a new python based tool is probably not the best investment of time
for the noobs. Experiences folks who already learned py-bcc will
keep hacking their scripts in python. That's all great.
noobs should probably learn bpftrace for quick experiments
and libbpf-tools for standalone long-term tried-and-true tools.

Should we keep libbpf-tools and py-bcc tools in sync?
I think py tools where libbpf-tools replacement is complete could be
moved into 'deprecated' directory and not installed by default.
All major distros are built with CONFIG_DEBUG_INFO_BTF=y
so the users won't be surprised. Their favorite tools will keep
working as-is. The underlying implementation of them will quietly change.
We can document it of course, but who reads docs.

Join iovisor-dev@lists.iovisor.org to automatically receive all group messages.