mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jin, Yao" <yao.jin@linux.intel.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org,
	mingo@redhat.com, alexander.shishkin@linux.intel.com,
	Linux-kernel@vger.kernel.org, ak@linux.intel.com,
	kan.liang@intel.com, yao.jin@intel.com
Subject: Re: [PATCH v2 4/4] perf: Support perf -vv
Date: Wed, 28 Mar 2018 22:56:25 +0800	[thread overview]
Message-ID: <f943f62c-0af2-7052-88a4-df9c7a978fa1@linux.intel.com> (raw)
In-Reply-To: <20180328141940.GA32321@krava>



On 3/28/2018 10:19 PM, Jiri Olsa wrote:
> On Wed, Mar 28, 2018 at 10:00:32PM +0800, Jin, Yao wrote:
>>
>>
>> On 3/28/2018 9:22 PM, Jiri Olsa wrote:
>>> On Wed, Mar 28, 2018 at 10:57:08PM +0800, Jin Yao wrote:
>>>> We keep having bug reports that when users build perf on their own,
>>>> but they don't install some needed libraries such as libelf,
>>>> libbfd/libibery.
>>>>
>>>> The perf can build, but it is missing important functionality.
>>>>
>>>> This patch provides a new option '-vv' which will print the
>>>> compiled-in status of libraries.
>>>>
>>>> The 'perf -vv' is equal to 'perf -version --build-options'.
>>>>
>>>> For example:
>>>>
>>>> $ ./perf -vv or ./perf -version --build-options
>>>> perf version 4.13.rc5.gcb1183
>>>>                    dwarf: [ on  ]
>>>>       dwarf_getlocations: [ on  ]
>>>>                    glibc: [ on  ]
>>>>                     gtk2: [ on  ]
>>>>                 libaudit: [ OFF ]
>>>>                   libbfd: [ on  ]
>>>>                   libelf: [ on  ]
>>>>                  libnuma: [ on  ]
>>>> numa_num_possible_cpus: [ on  ]
>>>>                  libperl: [ on  ]
>>>>                libpython: [ on  ]
>>>>                 libslang: [ on  ]
>>>>                libcrypto: [ on  ]
>>>>                libunwind: [ on  ]
>>>>       libdw-dwarf-unwind: [ on  ]
>>>>                     zlib: [ on  ]
>>>>                     lzma: [ on  ]
>>>>                get_cpuid: [ on  ]
>>>>                      bpf: [ on  ]
>>>> [ on  ]: library is compiled-in
>>>> [ OFF ]: library is disabled in make configuration
>>>>            OR library is not installed in build environment
>>>>
>>>> v2:
>>>> ---
>>>> Use a global variable version_verbose to count the number of 'v'.
>>>>
>>>> Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
>>>> ---
>>>>    tools/perf/perf.c | 22 ++++++++++++++++++----
>>>>    tools/perf/perf.h |  1 +
>>>>    2 files changed, 19 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
>>>> index 1b3fc8e..355219e 100644
>>>> --- a/tools/perf/perf.c
>>>> +++ b/tools/perf/perf.c
>>>> @@ -32,7 +32,7 @@
>>>>    #include <linux/kernel.h>
>>>>    const char perf_usage_string[] =
>>>> -	"perf [--version] [--help] [OPTIONS] COMMAND [ARGS]";
>>>> +	"perf [--version [--build-options]] [--help] [OPTIONS] COMMAND [ARGS]";
>>>
>>> --build-options is 'perf version' option no?
>>>
>>> jirka
>>>
>>
>> Yes. Command-line something like:
>>
>> perf --version --build-options or perf -v --build-options.
>>
>> Is this usage string not correct? If so, I'd like to fix that.
>>
>> "perf [--version [--build-options]] [--help] [OPTIONS] COMMAND [ARGS]";
> 
> ah I forgot that --version is in fact 'perf version'
> now I see --build-options depends on --version.. ok ;-)
> 
> could you please also create Documentation/perf-version.txt,
> now when it has option, we should document it
> 

That's fine. I will create the perf-version.txt.

> also please use the standard option parsing API we use in commands:
> 
>          argc = parse_options(argc, argv, record_options, record_usage,
>                              PARSE_OPT_STOP_AT_NON_OPTION);
> 
> so we get standard error when the option is mangled,
> unlinke now, when it's silent:
> 
> 	[jolsa@krava perf]$ ./perf --version --buil
> 	perf version 4.16.rc6.gcc183d
> 
> thanks,
> jirka
> 

Oh, yes. Let me check and update the code. Thanks so much for reminding 
this.

Thanks
Jin Yao

  reply	other threads:[~2018-03-28 14:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 14:57 [PATCH v2 0/4] " Jin Yao
2018-03-28 14:57 ` [PATCH v2 1/4] tools include: Add config.h header file Jin Yao
2018-03-28 14:57 ` [PATCH v2 3/4] perf version: Print the compiled-in status of libraries Jin Yao
2018-03-28 13:10   ` Jiri Olsa
2018-03-28 13:57     ` Jin, Yao
2018-03-28 14:57 ` [PATCH v2 4/4] perf: Support perf -vv Jin Yao
2018-03-28 13:22   ` Jiri Olsa
2018-03-28 14:00     ` Jin, Yao
2018-03-28 14:19       ` Jiri Olsa
2018-03-28 14:56         ` Jin, Yao [this message]
2018-03-28 15:46   ` Ingo Molnar
2018-03-29  0:52     ` Jin, Yao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f943f62c-0af2-7052-88a4-df9c7a978fa1@linux.intel.com \
    --to=yao.jin@linux.intel.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=yao.jin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome