Alternatively, the use of BPF without explanation signals that the article is a deep-dive and not intended for random passers-by. I don't support the position that every article should be written to cater to the lowest common denominator.
The first line of the article:
> Support for BPF in the kernel has been tied to the LLVM toolchain since the advent of extended BPF.
Should the article also explain which kernel they're referring to, what LLVM is and stands for, and highlight the differences between BPF and extended BPF? Or are they allowed to expect a motivated reader to do a cursory web search to fill in the gaps in their knowledge?
I disagree, you can always spend one or two sentences at the top to immediately bring everyone to a good starting point, regardless of how much technical depth the rest of the article has.
For example in this case: "eBPF is a method for user space to add code to the running Linux kernel without compromising security. They have been tied [...]. The GNU toolchain, the historical and still by many preferred system to build Linux currently has no support.
The description of what LWN and Linux is would be in the about page linked in the article.
It costs almost nothing for an expert to skim/skip two sentences while saving loads of time for everyone else.
The article is also completely missing motivation (why do we care whether BPF is supported in the second toolchain?) Which would be helpful for almost everyone, including people who think it is obvious.
Edit: To be clear though, I love LWN. But the articles are very often missing important context that would be easy to add that I suspect would help a large portion of the reader base.
A nice practice that I try to follow it to always spell out what any Three Letter Acronyms (TLAs) the first time they are used. Then from that point onwards the simple TLA can be used.
In this case, BPF (shorthand for eBPF), stands for Extended Berkley Packet Filter. It’s a relatively new feature in the kernel that allows attaching small programs at certain “hook points” in the kernel (for example, when some syscall is called). These programs can pass information into userspace (like who is calling the syscall), and make decisions (whether to allow the call to proceed).
We do try to spell things out and/or link them in LWN articles to make the context available, but some things we just have to assume.
Additionally, spelling out "Berkeley Packet Filter" is not going to help any readers here; BPF is far removed from the days when its sole job was filtering packets, and that name will not tell readers anything about why BPF is important in the Linux kernel.
Here is what I gathered without really ever checking.
It's a safe script that has access to part of the kernel and that unlocks a lot of monitoring. You could use a kernel module that's much unwieldy, error-prone etc.
The first line of the article:
> Support for BPF in the kernel has been tied to the LLVM toolchain since the advent of extended BPF.
Should the article also explain which kernel they're referring to, what LLVM is and stands for, and highlight the differences between BPF and extended BPF? Or are they allowed to expect a motivated reader to do a cursory web search to fill in the gaps in their knowledge?