Pythonbpf – Writing Ebpf Programs in Pure Python
Posted4 months agoActive4 months ago
xeon.meTechstory
calmpositive
Debate
40/100
EbpfPythonProgramming
Key topics
Ebpf
Python
Programming
The post introduces PythonBPF, a tool that allows writing eBPF programs in pure Python, sparking discussion on its potential, implementation, and comparison to other similar projects.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
3d
Peak period
16
72-78h
Avg / period
5.8
Comment distribution35 data points
Loading chart...
Based on 35 loaded comments
Key moments
- 01Story posted
Sep 12, 2025 at 7:29 AM EDT
4 months ago
Step 01 - 02First comment
Sep 15, 2025 at 3:53 AM EDT
3d after posting
Step 02 - 03Peak activity
16 comments in 72-78h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 16, 2025 at 10:38 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45221023Type: storyLast synced: 11/20/2025, 4:53:34 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
One nitpick: Please include a paragraph/section/infobox explaining what eBPF is and what problems should be solved using it. I am a huge fan of making our tech world more accessible and as such we should think to some degree about people who don't know every acronym.
Guessing this is BPF https://en.wikipedia.org/wiki/Berkeley_Packet_Filter But, reader shouldn't have to guess. That is the link that should be in your Introduction. Just after tldr;
[1]: https://lwn.net/Articles/740157/
It was definitely a toy, I transliterated from python bytecode (a stack based vm) into bpf. I also wrote the full code gen stack myself (bpf was simpler back then)
But using llvm and not marrying things to cpython implementation makes this approach way better
So, instead of having a defined and documented subset of Python that compiles to eBPF in a deterministic way... use an undefined pseudo language and let the LLM have fun with it without understanding if the result C is correct?
What would be the advantage?
And also, having an LLM translate Python-ish pseudo code into C does not imply that you cannot examine it before putting it into a program. You can manually review it and make modifications as you want. It just reduces time spent compared with writing C code by hand.
Would that represent a time advantage?
eBPF is a weird, formally validated secure subset of C. No "normal" C program will ever pass the eBPF validation checks.
Ask an LLM to write a simple ebpf program which kills any program with a specific name/path. Even crappy local models can handle this with ease.
If you’re talking about more complicated map-based programs, you’re probably right that it will struggle a bit, but it will still figure it out. The eBPF api is not very different than any other C api at the end of the day. It will do fine without the standard library, if you ask it to.
The issue here is the static formal validation the kernel does before loading your eBPF program.
(Even humans don't really know how it works. You need to use specific byte width types and access memory in specific patterns or the validation will fail.)
1. If you meant XDP, you should have said XDP, not eBPF.
2. The kernel does that validation on all ebpf code that it loads, regardless of whether XDP is involved.
3. Humans know how it works.
smh my head
Why would anyone go with the inaccurate option?
You can also write bpf in rust with Aya but i'm not sure how feature complete it is.
For very simple use cases you can just bpftrace.
Which is cool!
But the description could be a bit clearer.