lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 18 Feb 2016 23:40:23 +0100 From: Daniel Borkmann <daniel@...earbox.net> To: Tom Zanussi <tom.zanussi@...ux.intel.com> CC: Alexei Starovoitov <alexei.starovoitov@...il.com>, rostedt@...dmis.org, masami.hiramatsu.pt@...achi.com, namhyung@...nel.org, peterz@...radead.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [RFC][PATCH 00/10] Add trace event support to eBPF On 02/18/2016 10:27 PM, Tom Zanussi wrote: > On Tue, 2016-02-16 at 20:51 -0800, Alexei Starovoitov wrote: >> On Tue, Feb 16, 2016 at 04:35:27PM -0600, Tom Zanussi wrote: >>> On Sun, 2016-02-14 at 01:02 +0100, Alexei Starovoitov wrote: [...] >>>> Take a look at all the tools written on top of it: >>>> https://github.com/iovisor/bcc/tree/master/tools >>> >>> That's great, but it's all out-of-tree. Supporting out-of-tree users >>> has never been justification for merging in-kernel code (or for blocking >>> it from being merged). >> >> huh? perf is the only in-tree user space project. >> All others tools and libraries are out-of-tree and that makes sense. > > What about all the other things under tools/? > >> Actually would be great to merge bcc with perf eventually, but choice >> of C++ isn't going to make it easy. The only real difference >> between perf+bpf and bcc is that bcc integrates clang/llvm >> as a library whereas perf+bpf deals with elf files and standalone compiler. >> There are pros and cons for both and it's great that both are actively >> growing and gaining user traction. > > Why worry about merging bcc with perf? Why not a tools/bcc? It would indeed be great to mid-term have bcc internals to some degree merged(/rewritten) into perf. tools/bcc doesn't make much sense to me as it really should be perf, where already the rest of the eBPF front-end logic resides that Wang et al initially integrated. So efforts could consolidate from that side. The user could be given a choice whether his use-case is to load the object file, or directly pass in a C file where perf does the rest. And f.e. Brendan's tools could ship natively as perf "built-ins" that users can go and try out from there directly and/or use the code as a starting point for their own proglets. Cheers, Daniel
Powered by blists - more mailing lists