danobi

bpftrace has support for outputting pcap files now.

SEEKING VOLUNTEERS: bpftrace

As non-profit as it get! Intersection of operating systems, compilers, and observability. C/C++/LLVM.

https://github.com/bpftrace/bpftrace

"good first issue" or "easy" tag in issues is a good place to start looking for something to do. Or DM me and we can find something interesting.

What kind of events were being lost, and under what conditions? I'd like to see if it can be fixed.

Above two comments are very helpful, thanks. I've corrected the -m32 issue.

And thanks for pointing out the x86/ABI assumptions. Had not considered that. It's certainly interesting to think about.

I think it has to keep it for externally visible functions, right?

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.

I use stock ios and mobius sync works pretty well. No issues so far over 1y+ of use.

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.

Are there any docs for how it's implemented?

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.

Your metabolism can change during your life. Different people can also have different metabolisms.

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.

[0]: https://github.com/danobi/btrfs-fuzz

[1]: https://github.com/iovisor/bpftrace

Yes, exactly.

> 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.

Disclaimer: I wrote libbpf-rs.

[0]: https://github.com/libbpf/libbpf-rs

It's explained in the second paragraph in the article.

What if openat() or read() fails? More generally, what if there's a chain of syscalls and you _want_ one of them to fail?

I suggest taking a look at bpftrace ( https://github.com/iovisor/bpftrace ). The features and stability are getting quite good and better over time.

It actually turns out most of the calls are `openat(2)`. I had the same question initially.

How many times have you done "ls; cd <xx>; cd ..; ls; cd <yy>; etc"? With that tedium in mind, I set out to create a simple ncurses utility to combine ls and cd. As luck would have it, actually implementing the directory changing functionality was done last. I guess I have to chalk this one up to experience.