From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752953AbcFUB6T (ORCPT ); Mon, 20 Jun 2016 21:58:19 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:36408 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752725AbcFUB6N (ORCPT ); Mon, 20 Jun 2016 21:58:13 -0400 Subject: Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options To: Arnaldo Carvalho de Melo References: <1466064161-48553-1-git-send-email-wangnan0@huawei.com> <1466064161-48553-3-git-send-email-wangnan0@huawei.com> <20160616164815.GE13337@kernel.org> <57676309.8000907@huawei.com> <20160620143818.GA3050@redhat.com> CC: Arnaldo Carvalho de Melo , , , David Ahern , Namhyung Kim , Alexei Starovoitov , Jiri Olsa From: "Wangnan (F)" Message-ID: <57689F20.9060409@huawei.com> Date: Tue, 21 Jun 2016 09:57:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160620143818.GA3050@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57689F2C.001B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3f040d16b1cf5e5a1e2bc6aded2bb5f8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.