All of lore.kernel.org
 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 v1 2/3] perf version: Print the status of compiled-in libraries
Date: Tue, 27 Mar 2018 21:26:41 +0800	[thread overview]
Message-ID: <1f03bf56-4baa-e79e-84fe-17e9632fd09d@linux.intel.com> (raw)
In-Reply-To: <20180327123803.GF3102@krava>



On 3/27/2018 8:38 PM, Jiri Olsa wrote:
> On Mon, Mar 26, 2018 at 09:51:03PM +0800, Jin, Yao wrote:
>>
>>
>> On 3/26/2018 5:39 PM, Jiri Olsa wrote:
>>> On Tue, Mar 27, 2018 at 12:07:03AM +0800, Jin Yao wrote:
>>>> This patch checks the values passed by CFLAGS (-DXXX) and then
>>>> print the status of libraries.
>>>>
>>>> For example, if HAVE_DWARF_SUPPORT is defined, that means the
>>>> library "dwarf" is compiled-in. The patch will print the status
>>>> "on" for this library.
>>>>
>>>> Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
>>>> ---
>>>>    tools/perf/builtin-version.c | 125 +++++++++++++++++++++++++++++++++++++++++++
>>>>    tools/perf/builtin.h         |   1 +
>>>>    2 files changed, 126 insertions(+)
>>>>
>>>> diff --git a/tools/perf/builtin-version.c b/tools/perf/builtin-version.c
>>>> index 37019c5..90a0a7f 100644
>>>> --- a/tools/perf/builtin-version.c
>>>> +++ b/tools/perf/builtin-version.c
>>>> @@ -9,3 +9,128 @@ int cmd_version(int argc __maybe_unused, const char **argv __maybe_unused)
>>>>    	printf("perf version %s\n", perf_version_string);
>>>>    	return 0;
>>>>    }
>>>> +
>>>> +static void status_print(const char *name, const char *status)
>>>> +{
>>>> +	printf("%22s: [ %3s ]\n", name, status);
>>>> +}
>>>> +
>>>> +static void library_status(void)
>>>> +{
>>>> +#ifdef HAVE_DWARF_SUPPORT
>>>> +	status_print("dwarf", "on");
>>>> +#else
>>>> +	status_print("dwarf", "off");
>>>> +#endif
>>>
>>> could this and all those below be in some generic macro?
>>>
>>> #define STATUS(__d, __m)		\
>>> #ifdef __d 				\
>>> 	status_print(#__m, "on");	\
>>> #else					\
>>> 	status_print(#__m, "OFF");	\
>>> #endif
>>>
>>> STATUS(HAVE_DWARF_SUPPORT, dwarf)
>>>
>>>
>>> also please print the 'OFF' and use colors as in the build message
>>>
>>
>> Fine, thanks. I will update the code.
>>
>>>> +
>>>> +#ifdef HAVE_DWARF_GETLOCATIONS
>>>> +	status_print("dwarf_getlocations", "on");
>>>> +#else
>>>> +	status_print("dwarf_getlocations", "off");
>>>> +#endif
>>>> +
>>>> +#ifdef NO_GLIBC
>>>> +	status_print("glibc", "off");
>>>> +#else
>>>> +	status_print("glibc", "on");
>>>> +#endif
>>>> +
>>>> +#ifdef HAVE_GTK2_SUPPORT
>>>> +	status_print("gtk2", "on");
>>>> +#else
>>>> +	status_print("gtk2", "off");
>>>> +#endif
>>>> +
>>>
>>> SNIP
>>>
>>>> +}
>>>> +
>>>> +int cmd_version2(int argc, const char **argv)
>>>> +{
>>>> +	cmd_version(argc, argv);
>>>> +	library_status();
>>>> +	return 0;
>>>> +}
>>>> diff --git a/tools/perf/builtin.h b/tools/perf/builtin.h
>>>> index 05745f3..c7508ee 100644
>>>> --- a/tools/perf/builtin.h
>>>> +++ b/tools/perf/builtin.h
>>>> @@ -29,6 +29,7 @@ int cmd_timechart(int argc, const char **argv);
>>>>    int cmd_top(int argc, const char **argv);
>>>>    int cmd_script(int argc, const char **argv);
>>>>    int cmd_version(int argc, const char **argv);
>>>> +int cmd_version2(int argc, const char **argv);
>>>
>>> please don't add new command for this, handle this in cmd_version
>>>
>>
>> Yeah, I know that, adding a new command is not a good idea.
>>
>> But how can I pass a new parameter to cmd_version to indicate it's the -vv
>> case? Use argv[1]? But looks not good since argc is 1.
>>
>> Any idea about that?
> 
> I guess the based would be to have 'perf version -v', where
> in cmd_version you'd call standard option processing..
> 
> the 'perf -vv' shortcut could for example be done through
> some global var like in attached patch... untested
> 
> jirka
> 
> 
> ---
> diff --git a/tools/perf/builtin-version.c b/tools/perf/builtin-version.c
> index 37019c5d675f..1fe458792cc1 100644
> --- a/tools/perf/builtin-version.c
> +++ b/tools/perf/builtin-version.c
> @@ -4,6 +4,8 @@
>   #include <linux/compiler.h>
>   #include <stdio.h>
>   
> +int version_verbose;
> +
>   int cmd_version(int argc __maybe_unused, const char **argv __maybe_unused)
>   {
>   	printf("perf version %s\n", perf_version_string);
> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
> index 1b3fc8ec0fa2..a5c95c6c0de7 100644
> --- a/tools/perf/perf.c
> +++ b/tools/perf/perf.c
> @@ -185,7 +185,14 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
>   			break;
>   		}
>   
> -		if (!strcmp(cmd, "-v")) {
> +		if (strstarts(cmd, "-v")) {
> +			int i;
> +
> +			for (i = 2; cmd[i]; i++) {
> +				if (cmd[i] == 'v')
> +					version_verbose++;
> +			}
> +
>   			(*argv)[0] = "--version";
>   			break;
>   		}
> diff --git a/tools/perf/perf.h b/tools/perf/perf.h
> index 8fec1abd0f1f..9c45ba179635 100644
> --- a/tools/perf/perf.h
> +++ b/tools/perf/perf.h
> @@ -13,6 +13,8 @@ void test_attr__init(void);
>   void test_attr__open(struct perf_event_attr *attr, pid_t pid, int cpu,
>   		     int fd, int group_fd, unsigned long flags);
>   
> +extern int version_verbose;
> +
>   #define HAVE_ATTR_TEST
>   #include "perf-sys.h"
>   
> 

Using global variable, hmm, that's fine, looks no better way. :)

I will follow Ingo's suggestion. Use 'perf -v --build-options' and map 
it to 'perf -vv'.

Thanks
Jin Yao

  reply	other threads:[~2018-03-27 13:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 16:07 [PATCH v1 0/3] Support perf -vv Jin Yao
2018-03-26  9:00 ` Andi Kleen
2018-03-26  9:07   ` Jiri Olsa
2018-03-26 13:06     ` Jin, Yao
2018-03-26 16:07 ` [PATCH v1 1/3] perf config: Add -DNO_GLIBC to CFLAGS Jin Yao
2018-03-26 16:07 ` [PATCH v1 2/3] perf version: Print the status of compiled-in libraries Jin Yao
2018-03-26  9:39   ` Jiri Olsa
2018-03-26 13:51     ` Jin, Yao
2018-03-27  3:04       ` Jin, Yao
2018-03-27 12:38       ` Jiri Olsa
2018-03-27 13:26         ` Jin, Yao [this message]
2018-03-27  1:44     ` Jin, Yao
2018-03-27 12:56       ` Jiri Olsa
2018-03-27 13:17         ` Jin, Yao
2018-03-27 13:35           ` Jiri Olsa
2018-03-27  5:58   ` Ingo Molnar
2018-03-27  6:04     ` Jin, Yao
2018-03-26 16:07 ` [PATCH v1 3/3] perf: Support perf -vv Jin Yao
2018-03-27  6:03   ` Ingo Molnar
2018-03-27  6:12     ` 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=1f03bf56-4baa-e79e-84fe-17e9632fd09d@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.