From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752377AbcFTDaZ (ORCPT ); Sun, 19 Jun 2016 23:30:25 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:41698 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751839AbcFTDaV (ORCPT ); Sun, 19 Jun 2016 23:30:21 -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> CC: , , "Arnaldo Carvalho de Melo" , Alexei Starovoitov , Jiri Olsa From: "Wangnan (F)" Message-ID: <57676309.8000907@huawei.com> Date: Mon, 20 Jun 2016 11:29:13 +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: <20160616164815.GE13337@kernel.org> 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.57676348.003E,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/17 0:48, Arnaldo Carvalho de Melo wrote: > Em Thu, Jun 16, 2016 at 08:02:41AM +0000, Wang Nan escreveu: >> With '--dry-run', 'perf record' doesn't do reall recording. Combine with >> llvm.dump-obj option, --dry-run can be used to help compile BPF objects for >> embedded platform. > So these are nice and have value, but can we have a subcommand to do all > this with an expressive name, Something like: > > perf bpfcc foo.c -o foo > > or shorter: > > perf bcc foo.c -o foo > > Just like one would use gcc or some other compiler to generate something > for later use? I'll try it today. I thought a subcommand require a bigger feature, and wrapping clang is not big enough. > That if called as: > > perf bcc foo.c > > Would default to generating a foo.o file. > > Then, later, one could use this as a event name, i.e. > > trace --event foo > > Would, knowing that there is no event named "foo", look at the current > directory (and in some other places perhaps) for a file named "foo" that > was a bpf object file to use as it would a foo.c, shortcircuiting the > bpf compilation code. > If this was done instead: > > trace --event foo.c > > And foo.c wasn't present, it would fallback to the behaviour described > in the previous paragraph: look for a foo.o or foo bpf object file, etc. > > What do you think? I'm not sure how many people can be benified from this feature. The only advantage I can understand is we can skip the '.c', '.o' or '.bpf' suffix. I guess what you really want is introducing something like buildid-cache for BPF object. One can compile his/her BPF scriptlets into .o using 'perf bcc' and insert it into cache, then he/her can use the resuling object without remembering the path of it. 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? Thank you.