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:
About fallback, if user explicitly uses '.o' or '.bpf' as suffix ourWell there is a namespace issue here, if we say:
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?
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.