linux-kernel - Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

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: <57689F20.9060409@huawei.com>
Date:	Tue, 21 Jun 2016 09:57:52 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
CC:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	<linux-kernel@...r.kernel.org>, <pi3orama@....com>,
	David Ahern <dsahern@...il.com>,
	Namhyung Kim <namhyung@...il.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline
 options



On 2016/6/20 22:38, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 20, 2016 at 11:29:13AM +0800, Wangnan (F) escreveu:
>> On 2016/6/17 0:48, Arnaldo Carvalho de Melo wrote:
>>> Em Thu, Jun 16, 2016 at 08:02:41AM +0000, Wang Nan escreveu:

[SNIP]

>> About fallback, if user explicitly uses '.o' or '.bpf' as suffix our
>> parser can be easier. Technically we need a boundary to split event
>> name and configuration.  '.c', '.o' and '.bpf' are boundaries. In
>> addition, is there any difference between '-e mybpf' and '-e
>> mybpf.bpf'? We can define that, when using '-e mybpf' the search path
>> whould be the BPF object cache, when using '-e mybpf.bpf' the search
>> path is current directory. It is acceptable, but why not make '-e
>> mybpf.bpf' search BPF object cache also?
> Well there is a namespace issue here, if we say:
>
> 	perf record -e cycles
>
> then this is well known, we want PERF_TYPE_HARDWARE,
> PERF_COUNT_HW_CPU_CYCLES. If we instead use:
>
> 	perf record -e cycles.c
>
> Then this also is well known, we need to build this somehow, and right
> now the only way to do this is to use the llvm/clang infrastructure and
> then load it into the kernel via sys_bpf.
>
> If we say:
>
> 	perf record -e cycles.bpf
>
> Then we don't have anything associated with this and may go on trying to
> map it to a PERF_TYPE_HARDWARE, PERF_TYPE_SOFTWARE, etc till we find a
> suitable event, i.e. if it doesn't match anything, we would end up
> looking at a file in the current directory, figure out it is an ELF file
> and that its contents are a BPF proggie, that we would load via sys_bpf,
> etc.

cycles.bpf is not a good example. See tools/perf/util/parse-events.l:
   ...
   bpf_object      .*\.(o|bpf)
   ...

currently '.o' equals to '.bpf'.

Thank you.