Alastair Robertson

I'm fully behind us adding support for real functions in bpftrace. That being said, I can still see a use for function-like macros. For example, we'd be able to implement...

Agreed that this would be a useful feature to have. But it'd be nicer if we could make it more composable - i.e. able to call an iterator from another...

To be honest I'm not very happy with the current syntax of having iterators iterators as a top-level probe type: - The language is otherwise event-driven, but iterators break that...

> > if a probe calls an iterator, disallow anything else in that probe's body. > > Since the bounding probes (e.g. `BEGIN`, `interval`) are all in userspace, do you...

With BPF's new open-coded iterators, it sounds like we might be able to implement this entirely inside BPF (without any async-action nastiness). The list of supported open-coded iterators isn't as...

I've got a user who needs this urgently so am picking it up today

Closed by #3003

Newer kernels have the "open-coded iterator", `bpf_for`, which lets us write loops without having to use callback functions: https://lwn.net/Articles/925751/. We could just target kernels with support for `bpf_for` to make...

I'd prefer that we keep explicit formatting out of the `print()` function, but there are two other enhancements (both useful by themselves) that we could make to improve this type...

Closing as resolved by #3003. Something similar to the original example can now be implemented as: ``` $ sudo bpftrace -e ' BEGIN { @[0xfeedface] = 1; @[0xbaadcafe] = 2;...