Delyan Kratunov

> I think running bpftrace in lockstep with libbpf is a good solution. We might initially prevent users on older distros from building bpftrace Oh, but that's the thing -...

> because it uses both libbpf and bcc. The latter is what fails on older kernels. Right, a lot of the refactoring here will involve moving things to use libbpf's...

@Conan-Kudo feel free to start a discussion at the libbpf repo here on GitHub or on the bpf mailing list. In this issue, we don't really control how libbpf is...

Closing as resolved. POR is to vendor libbpf for local builds and clearly state the dependencies, moving libbpf along as it gains features we need. Let's discuss the actual work/steps...

> What do you mean by 0th level here? Sorry, that was poorly worded. I'm suggesting that `filter(@, 0, $val)` can return the subset of keys where the first element...

> If delete is allowed from the callback it would be interesting. It is allowed for hash maps (delete doesn't do anything for array maps), [here it is in the...

Okay, I spent some time working on this and have a couple of concerns. Primarily, the way static functions (aka subprogs in bpf lingo) work is not compatible with how...

> Patch bpftrace's current logic to emit .BTF.ext Ha, and I thought this would be easy.. bpftrace is currently not using the DIBuilder at all. This means LLVM can't generate...

Yup, didn't know that existed. What prevented the merge of that PR?

> you do have to be careful about race conditions I'm not suggesting that we keep the data _only_ in the map. I'm suggesting that we simply pass map pointers...