linux-kernel - Re: [RFC PATCH v10 23/50] perf tools: Make perf depend on libbpf

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: <559D0D5E.60901@huawei.com>
Date:	Wed, 8 Jul 2015 19:45:34 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	<ast@...mgrid.com>, <brendan.d.gregg@...il.com>,
	<daniel@...earbox.net>, Namhyung Kim <namhyung@...nel.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
	David Ahern <dsahern@...il.com>,
	<linux-kernel@...r.kernel.org>, <lizefan@...wei.com>,
	<hekuang@...wei.com>, <xiakaixu@...wei.com>, <pi3orama@....com>
Subject: Re: [RFC PATCH v10 23/50] perf tools: Make perf depend on libbpf



On 2015/7/8 4:16, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 07, 2015 at 04:54:52PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Jul 01, 2015 at 02:14:11AM +0000, Wang Nan escreveu:
>>> By adding libbpf into perf's Makefile, this patch enables perf to
>>> build libbpf during building if libelf is found and neither NO_LIBELF
>>> nor NO_LIBBPF is set. The newly introduced code is similar to libapi
>>> and libtraceevent building in Makefile.perf.
>>> MANIFEST is also updated for 'make perf-*-src-pkg'.
>>> Append make_no_libbpf to tools/perf/tests/make.
>>> 'bpf' feature check is appended into default FEATURE_TESTS and
>>> FEATURE_DISPLAY, so perf will check API version of bpf in
>>> /path/to/kernel/include/uapi/linux/bpf.h. Which should not fail
>>> except when we are trying to port this code to an old kernel.
>>>
>>> Error messages are also updated to notify users about the disable of
>>> BPF support of 'perf record' if libelf is missed or BPF API check
>>> failed.
>> Much better!
> <SNIP>
>
>> Auto-detecting system features:
> <SNIP>
>
>> ...                           bpf: [ on  ]
> <SNIP>
>
> But... I was all happy about this being linked with perf, went straight
> ahead to try to use it! No, its not possible, I have to go thru a series
> of other patches first... anticlimactic :-(
>
> So, please move this to just before we can use it, wiring it up should
> mean, hey, try this "hello, world" eBPF program right now!

It is not an easy work, since there is a bulk of code in 
tools/perf/utils/bpf-loader.c
depend on HAVE_LIBBPF_SUPPORT and CONFIG_LIBBPF. If put this patch the
final one, we will make hundreds of lines of code avaiable by one patch.
It is not good.

I have an idea that, put this patch after the llvm tester:

$ git log --oneline
d011a28 perf tools: Make perf depend on libbpf
57ad12f perf tests: Add LLVM test for eBPF on-the-fly compiling
8c7e20b perf tools: Auto detecting kernel include options
442675f perf tools: Auto detecting kernel build directory
dcd9304 perf tools: Call clang to compile C source to object code
864e2fb perf tools: Introduce llvm config options
8558c38 bpf tools: Link all bpf objects onto a list
...

Then before this patch, you can test llvm on-the-fly compiling without 
parsing the
result .o:

$ perf test 38
38: Test LLVM searching and compiling                        : (skip bpf 
parsing) Ok

After this patch, libbpf should be compiled so basic libbpf parsing can 
be tested:

$ perf test 38
38: Test LLVM searching and compiling                        : Ok



> And please consider using the patches in the tmp.perf/ebpf branch in my
> tree, the code contents are the same as yours, but I did some changes to
> the comment texts, fixing some typos, etc.
>
> Also I fixed up the first two patches, the ones for the kernel, as it
> was conflicting with some patches, including one where Steven Rostedt
> renamed some trace_events structs and file names, that previously had
> "ftrace" in it.
>
> Also next time please leave all this in a git branch I can try, to be
> able to try the end result, doing that may help me while doing the next
> review.
>
> I'll have to stop for today, will try as soon as you address the
> comments to go back working on this.
>
> Thanks!
>
> - Arnaldo


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/