Before We Begin

• 1: Author
• 2: Copyright
• 3: Preface
• 4: Contribution Guidelines
• 5:

1 - Author

Author

Hamza Megahed

2 - Copyright

License

© 2025 Hamza Megahed – Engineering Everything with eBPF

License: Creative Commons Attribution 4.0 International (CC BY 4.0)
This license lets anyone copy, redistribute, remix, transform, and build upon the material for any purpose—even commercially—so long as they give appropriate credit and indicate if changes were made.

Code Licenses

Disclaimer

Running eBPF programs generally requires root access or the CAP_BPF capability. The kernel verifier guards against crashes, but inefficient or incorrectly attached programs can still degrade performance or disrupt networking. Test all examples on a non-production system first. Neither the author shall be liable for any damages arising from the use of this material.

Running eBPF programs requires elevated privileges and can affect system stability. Follow the examples at your own risk. Neither the author nor the publisher shall be liable for any damages arising from the use of this material.

3 - Preface

Hello and welcome. Engineering Everything with eBPF is your friendly guide to eBPF on Linux. eBPF lets you run tiny programs inside the kernel so you can watch what the system is doing, filter network traffic, and even add safety checks—all without changing kernel source code. That sounds powerful, and it is. But it can also feel confusing the first time you see strange section names like SEC("xdp") or long helper calls. Do not worry. Every chapter walks you through one small idea at a time, then shows a real example working on your own machine.

Why this book exists
When I began learning eBPF, I kept bouncing between blog posts and mailing-list threads, piecing things together. I wrote Engineering Everything with eBPF so you do not have to repeat that maze. You will start by loading a five-line program, see the result right away, and gradually build up to practical tools for tracing disk I/O, shaping network traffic, and securing containers.

Plain language, lots of examples
I use short sentences, clear words, and plenty of code. Each new term—map, verifier, tail call—appears next to a tiny program you can copy, run, and explore. After you run the code, the explanation will make more sense. If something still feels cloudy, keep reading; later chapters revisit the idea from a different angle.

Tested environment
All code listings were compiled and executed on Linux kernel 6.12.22, with Clang/LLVM 17 and libbpf 1.5. If you use this kernel (or a newer one) the examples should work exactly as printed. When newer kernels add handy helpers or map types, I point them out and tell you whether you need to adjust your code.
Every example used in this book lives in the public repository

https://github.com/Hamza-Megahed/Engineering-Everything-with-eBPF-Code

What you need

• A Linux box or virtual machine with kernel 6.12.22+
• clang, lld, make, and typical build tools
• Root access (or the CAP_BPF capability) to load programs
• A sense of curiosity—nothing else

How to read
Skim first, run later. Browse the chapter, copy the program, run it, then come back and read the full explanation. Learning speeds up when you see the output with your own eyes. If a term is still unclear, do not worry; it often becomes obvious after the next example.

By the final chapter you will have a small toolbox of eBPF programs you can adapt to real-world tasks—debugging, performance tuning, or keeping a service safe. Take your time, run the code, and enjoy the process. Everything will click, step by step. Let’s begin our journey into eBPF together.

4 - Contribution Guidelines

We’re happy you want to make Engineering Everything with eBPF better.
The steps below keep changes smooth and easy.

1. Open an issue first

   • Create a GitHub issue for typos, unclear text, new examples, or bugs in sample code.
   • Show what you saw and what you expect instead. Screenshots or terminal output help a lot.

2. Fork the repo and create a branch

   • Fork, then name your branch clearly—­for example fix-ringbuf-example or add-cgroup-section.

3. Write in the same simple style

   • Short sentences, plain English.
   • Use fenced code blocks (```c for C, ```bash for shell).
   • Wrap Markdown lines at about 80 characters so diffs stay readable.

4. Test what you add

   • All examples must build and run on at least Linux 6.12.22, Clang/LLVM 17, and libbpf 1.5—or newer.
   • If you change existing code, run it to confirm the output still matches the book.
   • Add a short comment showing expected output if it helps readers verify success.

5. Open a pull request

   • Reference the related issue (for example, Fixes #123).
   • In the PR description, explain why you made the change and how you tested it.
   • CI checks will compile the code and build the book; please wait for them to pass.

6. Review process

   • We aim to review within a week. Friendly suggestions are normal—feel free to ask for clarification.
   • Once approved, a maintainer will merge and include your name in the release notes.

7. Licensing

   • Kernel eBPF source files
     • If the file contains

       char LICENSE[] SEC("license") = "GPL";
       

       it is contributed under GPL-2.0-or-later so it can use GPL-only helpers.
     • You may instead set the string to "BSD", "MIT", or any SPDX-compatible identifier if you prefer a more permissive license.
       • Important: the kernel will then not allow GPL-only helpers; choose this path only if your code does not need them.
       • State your chosen license in the file header so readers know the terms.
   • User-space loaders, scripts, and utilities are Apache 2.0 by default (mention in the header if you prefer GPL).
   • Book text and diagrams remain Creative Commons BY 4.0.

8. Code of Conduct

   • We follow the Contributor Covenant v2.1. Please be respectful, patient, and welcoming. That’s it! Thank you for helping more people engineer everything with eBPF.

5 -