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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56C64857.1090502@iogearbox.net>
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