BPF_PROG_RUN is great but unfortunately depends on the running kernel version. To that end, I wrote `vmtest` (https://dxuuu.xyz/vmtest.html) which is designed for the BPF_PROG_RUN use case.
Was threading support ever added? I recall there being a few attempts. I tried aerc out for quite a bit but ultimately had to give it up for neomutt b/c mailing list discussions were impossible to follow without threading support.
Completely agree. FWIW, I think procedural macros make a huge difference for ergonomics. For example, a "similar" library in C++ (libcereal) is still a PITA to use and debug.
Because you can’t add a feature with a knob. And not all changes can be made in a module (eg core kernel). And even if they could, kernel internals are not stable and you would still need to rebase your out of tree modules.
Both parts (compiler backends & fuzzing) are immensely complicated stuff on their own. I can only imagine the trickery and head scratching that comes with the combination.
I’ve worked on simpler approximations of both [0][1] before and can attest even the simple parts are hard to get working reliably.
> It looks like systemd-oomd is related to (based on? from the same people as?) Facebook's oomd
Yep, I authored the original standalone oomd (along with many others' help) and Anita has been working on systemd-oomd. There's plans to converge and simplify everything that's been learned from oomd into systemd-oomd so the community can benefit from all our experiments.
When a cgroup hits its memory.max the kernel OOM killer is invoked. systemd-oomd enables finer grained policy than the kernel OOM killer. systemd-oomd can also prevent livelocks (which memory.max does not).
A possibly lighter weight alternative is libbpf-rs [0]. libbpf-rs is designed to take advantage of BPF's Compile-Once-Run-Everywhere functionality where you can ship a pre-compiled object file to production instead of an entire compiler toolchain.