In eBPF-land you're going to be calling C functions in the kernel, and using (generally) C data types like structs and null-terminated strings. You can't do loops (loops are unrolled by the compiler), you can't do variadic functions, and you definitely can't take advantage of all the cool Go stuff like goroutines, select, context, etc.
I'm not really sure why you'd want to use this. If you're writing eBPF, you already need to know how to read C kernel source.
> Acronyms often confuse readers. Avoid them whenever possible. If an acronym is necessary for future reference, spell the full word and follow with the acronym in parentheses on the first reference. For example, The General Services Administration (GSA).
In fairness to the authors README, there isn't really any other BPFs in this domain and if someone didn't already know what BPF was, then this project wouldn't be of any interest to them (and would be a bad place to start on an BPF journey too).
So I can't blame the project's author for the lack of explanation about what BPF is. Particularly when it's just someone's personal project.
And before anyone complains about this comment: I do think the GP is completely fair in asking for clarification as to what BPF is too. There sometimes seems to be backlash on HN against people asking for a term to be explained. This comment isn't that.
Sure, but if you are sharing with a general audience (where people aren't necessarily coming from your own domain) it's a good idea to make the writing accessible.
My first thought would have been Band-Pass Filter, which is also a filter potentially related to computer systems.
I work in an industry with a lot of Three-Letter Acronyms (TLAs) and eXtended Three-Letter Acronyms (XTLAs) (sometimes known as Four-Letter Acronyms (FLAs)), and there they are often overloaded in their meanings. So in my experience, being clear about the definition is helpful to readers so they can immediately understand the document without having to triangulate meanings from the rest of the document.
I'm not really sure why you'd want to use this. If you're writing eBPF, you already need to know how to read C kernel source.
This is why NASA's guidance is the following:
> Acronyms often confuse readers. Avoid them whenever possible. If an acronym is necessary for future reference, spell the full word and follow with the acronym in parentheses on the first reference. For example, The General Services Administration (GSA).
https://nasa.github.io/content-guide/abbreviations-and-acron...
There is also this longer memo on the NASA Technical Reports Server: https://ntrs.nasa.gov/citations/19950025292
So I can't blame the project's author for the lack of explanation about what BPF is. Particularly when it's just someone's personal project.
And before anyone complains about this comment: I do think the GP is completely fair in asking for clarification as to what BPF is too. There sometimes seems to be backlash on HN against people asking for a term to be explained. This comment isn't that.
My first thought would have been Band-Pass Filter, which is also a filter potentially related to computer systems.
I work in an industry with a lot of Three-Letter Acronyms (TLAs) and eXtended Three-Letter Acronyms (XTLAs) (sometimes known as Four-Letter Acronyms (FLAs)), and there they are often overloaded in their meanings. So in my experience, being clear about the definition is helpful to readers so they can immediately understand the document without having to triangulate meanings from the rest of the document.
Not quite as much as Radar or Laser, but halfway there.
Here you go: https://github.com/pratyushanand/learn-bpf