[Proposal] Remove B frontend and P4 language support #3682
Comments
davemarchevsky
added a commit
to davemarchevsky/bcc
that referenced
this issue
Dec 17, 2021
Remove support for compiling B programs (see iovisor#3682 for explanation). There may be some vestigial logic in other files that needs to be cleanded up for simplicity - bpf_module.cc most likely - but that can be addressed in followup commits. Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
davemarchevsky
added a commit
to davemarchevsky/bcc
that referenced
this issue
Dec 17, 2021
Remove support for compiling P4 programs (see iovisor#3682 for explanation). Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
yonghong-song
pushed a commit
that referenced
this issue
Dec 17, 2021
Remove support for compiling B programs (see #3682 for explanation). There may be some vestigial logic in other files that needs to be cleanded up for simplicity - bpf_module.cc most likely - but that can be addressed in followup commits. Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
yonghong-song
pushed a commit
that referenced
this issue
Dec 17, 2021
Remove support for compiling P4 programs (see #3682 for explanation). Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
|
#3759 did this |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What
The B language is a custom tracing language supported by BCC (example program, frontend directory w/ lexer, parser, loader). P4 is a packet processing DSL which bcc can translate into bcc-style BPF C programs (example program, frontend directory). Both allow users to write high-level BPF programs.
The B support is implemented as a proper LLVM frontend which has some interaction with BCC's custom FrontendAction and loader functionality, while the P4 support is in the form of a transpiler that produces bcc-style C programs.
Why
It's unclear if anyone is using these two languages to write BPF programs today or actively maintaining BPF programs written in these languages. Neither language's frontends have been touched in many years (active development seems to have been 2015-2017 for both) and none of the folks actively working on BCC tools and core functionality are familiar with them. The community overwhelmingly uses bcc- and libbpf-style C for tools.
I'm currently refactoring and simplifying BCC's internals to better match libbpf loader conventions. The internals have been stable for the past few years, so these large changes are likely to break B language support in subtle ways. This is a reasonable time to announce that B is no longer supported and rip out the integration. The alternative is continuing to make small fixes to ensure code compiles and tests pass, but not having confidence that edge cases are covered and things actually work.
Although P4's transpilation is unlikely to break as a result of these changes, the other logic for removal still holds.
When
This issue will remain open for at least a month before any action is taken
Alternatives
Folks from the community volunteering to maintain the B frontend and P4 transpiler would be a viable alternative. Learning about current use cases for these languages might convince folks who actively maintain bcc to pay some attention to B and P4.
The text was updated successfully, but these errors were encountered: