On Mon, 2 Mar 2015 11:14:54 -0800 Alexei Starovoitov <a...@plumgrid.com> wrote: > I think we both want to see in-kernel aggregation. > This 'hist' stuff is trying to do counting and even map sorting > in the kernel, whereas with bpf programs I'm moving > all of these decisions to user space. > I understand your desire to avoid any user level scripts > and do everything via 'cat' and debugfs, but imo that's > very limiting. I think it's better to do slim user space > scripting language that can translate to bpf even in > embedded setups. Then users will be able to aggregate > whatever they like, whereas with 'hist' approach > they're limited to simple counters. > trace_events_trigger.c - 1466 lines - that's quite a bit > of code that will be rarely used. Kinda goes counter > to embedded argument. Why add this to kernel > when bpf programs can do the same on demand?
At Collab, a lot of people came to me telling me they love the debugfs system. Because it's everywhere they go. You remove that, you remove most users (including myself). > Also the arguments about stable ABI apply as well. > The format of 'hist' file would need to be stable, so will > be hard to extend it. With bpf programs doing aggregation > the kernel ABI exposure is much smaller. I disagree with this statement. > So would you consider working together on adding > clean bpf+tracepoints infra and corresponding > user space bits? > We can have small user space parser/compiler for > 'hist:keys=common_pid.execname,id.syscall:vals=hitcount' > strings that will convert it into bpf program and you'll > be able to use it in embedded setups ? Make sure it also works on android. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/