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: 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.
Powered by blists - more mailing lists