https://lwn.net/Articles/786927/ This is a special feed containing comments posted to the individual LWN article titled "An eBPF overview, part 3: Walking up the software stack (Collabora blog)". en-us Sat, 18 Oct 2025 19:18:31 +0000 Sat, 18 Oct 2025 19:18:31 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net https://lwn.net/Articles/787167/ https://lwn.net/Articles/787167/ adirat <div class="FormattedComment"> Only part of what makes a "complete" eBPF program is compiled to eBPF bytecode and executed by the VM, the rest is run as a normal native user process (the loader, the frontend parts from the article) - these are the parts which read the data structures exposed by the in-kernel eBPF VM (backend) code and can segfault, leak memory, and so on. BCC provides Python and LUA bindings to make these parts easier/safer to write, there are also Go bindings outside the BCC project (<a href="https://github.com/iovisor/gobpf">https://github.com/iovisor/gobpf</a>), but OFC no language is a silver bullet, bad code is bad code in any language :) <br> </div> Tue, 30 Apr 2019 17:39:11 +0000 https://lwn.net/Articles/787163/ https://lwn.net/Articles/787163/ rweikusat2 <div class="FormattedComment"> Considering that eBPF programs are supposed to be executed by a 'safe' virtual machine, how can it be "dangerous" to write such programs in C?<br> <p> </div> Tue, 30 Apr 2019 16:46:05 +0000