On Tue, Mar 26, 2024 at 9:18 PM Eric Dumazet <[email protected]> wrote: > > On Tue, Mar 26, 2024 at 11:44 AM Jason Xing <[email protected]> wrote: > > > Well, it's a pity that it seems that we are about to abandon this > > method but it's not that friendly to the users who are unable to > > deploy BPF... > > It is a pity these tracepoint patches are consuming a lot of reviewer > time, just because > some people 'can not deploy BPF'
Sure, not everyone can do this easily. The phenomenon still exists and we cannot ignore it. Do you remember that about a month ago someone submitted one patch introducing a new tracepoint and then I replied to/asked you if it's necessary that we replace most of the tracepoints with BPF? Now I realise and accept the fact... I'll keep reviewing such patches and hope it can give you maintainers a break. I don't mind taking some time to do it, after all it's not a bad thing to help some people. > > Well, I came up with more ideas about how to improve the > > trace function in recent days. The motivation of doing this is that I > > encountered some issues which could be traced/diagnosed by using trace > > effortlessly without writing some bpftrace codes again and again. The > > status of trace seems not active but many people are still using it, I > > believe. > > 'Writing bpftrace codes again and again' is not a good reason to add > maintenance costs > to linux networking stack. I'm just saying :)
