Re: [RFC][PATCH 00/10] Add trace event support to eBPF

[Daniel Borkmann]

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