Jordan Rome
Jordan Rome
I also like Option 3 but more so I like the idea of the user having to do and think about less; provided we're not creating a leaky abstraction. What...
> But we probably want to keep JSON output as-is so tooling doesn't silently break. Would be nice if we could provide a way to print the symbolized enums in...
> I think changing the human output is fine but JSON is dicey. As folks may be parsing it in prod already. I guess we'll see if we get requests...
@gustavogabaldon - Sorry, @aaliyahnl has already started work on this but please feel free to grab another task from the backlog.
Here are a few that might be good: - https://github.com/bpftrace/bpftrace/issues/1151 - https://github.com/bpftrace/bpftrace/issues/1986 - https://github.com/bpftrace/bpftrace/issues/3293
@keosung Looking forward to your contribution! It's all yours. Please see this PR for inspiration: https://github.com/bpftrace/bpftrace/pull/3470
I'm also for 2nd option for now (for the reasons @ajor mentioned). I think we can punt on the decision to add a new probe type later when there is...
Still tinkering with @amscanne 's prototype but I think we attach too fast to see "progress" (especially when 'multi' is available) https://github.com/bpftrace/bpftrace/pull/4202
One other challenge with this is updating the progress bar while warning messages from attachment failure are being printed.