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

From: Wangnan (F)
Date: Mon Jun 20 2016 - 21:58:25 EST




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.