Daniel Xu
Daniel Xu
Done, closing like suggested by Viktor
Maybe you have a different clang-format version installed. You could try using the CI version: https://github.com/bpftrace/bpftrace/blob/75e830ca52ce07b1cf2f934aa48de35aca8ce52e/.github/workflows/ci.yml#L20
IMO the use of `operator()` makes everything look too much like a function call. Which I suppose on a really technical level is true. But kinda misleading to read still....
> > IMO the use of `operator()` makes everything look too much like a function call. Which I suppose on a really technical level is true. But kinda misleading to...
Closing due to inactivity.
Apologies in advance if this sends you on bit of a side quest, but BPF_PROG_TYPE_RAW_TRACEPOINT was added in 4.17 kernel: https://github.com/torvalds/linux/commit/a0fe3e574b50461c4811ce81811f0eaefda62871 bpftrace's policy w.r.t. old kernels is we support up...
> @danobi just to make sure i got your point correctly, now we don't need to attach the special probes to anyting? calling `bpf_prog_test_run_opts` would be enough, right? Yes, that's...
> @viktormalik - Making sure you saw my comment above. What do you think about `self:signal:SIGUSR` instead of `bpftrace:signal:SIGUSR`? Hmm, I bpftrace prefix is ok. Maybe I write too much...
:P sure. Sounds like `self` is shorter and less ambiguous for future use cases. `or we could do "this"`
Did a quick skim - didn't spot any major issues