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

[Wangnan (F)]

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.