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?

I like the tweak-ability of the Python tools: sometimes I'm on a
production instance and I'll copy a tool and edit it on the fly. That
won't work with libbpf. Although, we also install all the bpftrace
tools on our prod instances [0], and if I'm editing tools I start with
them.

However, the llvm dependency of the Python tools is a pain, and an
obstacle for making bcc tools a default install with different
distros. I could imagine having a selection of the top 10 libbpf tools
as a package (bcc-essentials), which would be about 1.5 Mbytes (last
time I did libbpf tool it was 150 Kbytes stripped), and getting that
installed by default by different distros. (Ultimately, I want a
lightweight bpftrace installed by default as well.)

So, I guess I'm not certain about the future of the BCC Python tools.
What do people think? If we agree that the Python tools are legacy, we
should update the README to let everyone know.

Note: I'm just talking about the tools (tools/*.py)! I imagine BCC
Python is currently used for many other BPF things, and I'm not
suggesting that go away.

Brendan

[0] https://github.com/Netflix-Skunkworks/bpftoolkit

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.