All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taeung Song <treeze.taeung@gmail.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	Namhyung Kim <namhyung@kernel.org>
Cc: linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH v8 3/4] perf config: Prepare all default configs
Date: Thu, 21 Apr 2016 00:29:16 +0900	[thread overview]
Message-ID: <5717A04C.1080403@gmail.com> (raw)
In-Reply-To: <20160420132236.GM3677@kernel.org>

Hi, Arnaldo :-)

On 04/20/2016 10:22 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Apr 20, 2016 at 09:44:38PM +0900, Namhyung Kim escreveu:
>> On Mon, Apr 18, 2016 at 11:55:18PM +0900, Taeung Song wrote:
>>> On 04/15/2016 01:42 AM, Taeung Song wrote:
>>>> On 04/14/2016 09:19 PM, Arnaldo Carvalho de Melo wrote:
>>>>> Em Thu, Apr 14, 2016 at 04:53:20PM +0900, Taeung Song escreveu:
>>>>>> +++ b/tools/perf/util/config.c
>>>>>> @@ -15,6 +15,7 @@
>>>>>> +#define MAX_CONFIGS 64
>
>>>>> Do we have to add another arbitrary maximum? Where is it used?
>
>>>> IMHO, it is my idea. If you want to avoid using this arbitrary maxinum,
>>>> I'd modify the code.
>>>>
>>>> MAX_CONFIGS is used in order to declare two-dimensional arrays
>>>> 'default_config_items'
>
>>> As above, I used MAX_CONFIGS because of two-dimensinal arrays
>>> 'default_config_items'.
>
>>> What do you think about it ?
>
>> I also agree that we'd better to avoid the arbitrary maximum.
>
>>> We don't need to add this arbitrary maximum ?
>>> or would you mind, if I look for other way about
>>> 'default_config_item' ?
>>
>> What about this?
>
> Yeah, I guess this should work, no? At least this is how it is done
> elsewhere, see:
>
> tools/perf/builtin-bench.c, 'struct collection' has a benchmarks array,
> that in turn is organized as Namhyung suggests.

I got it!

> Then you either use ARRAY_SIZE() somewhere to get the number of entries
> or use a sentinel, i.e. use NULL for the last entry.
>

I think that it would better to use ARRAY_SIZE() than to use NULL.
It makes no odds but it seem to be clean, IMHO. :)

After changing this patchset, I'll send v9 !

Thanks,
Taeung

>
>> struct perf_config_item color_config_items[] = {
>> 	CONF_STR_VAR("top", "red, default"),
>> 	CONF_STR_VAR("medium", "green, default"),
>> 	...
>> };
>>
>> struct perf_config_item tui_config_items[] = {
>> 	CONF_BOOL_VAR("report", true),
>> 	CONF_BOOL_VAR("annotate", true),
>> 	...
>> };
>>
>> struct perf_config_item *default_config_items[] = {
>> 	&color_config_items,
>> 	&tui_config_items,
>> 	...
>> };
>>
>> This way we can access the config array by using constant index
>> without the hard-coded maximum size IMHO.
>>
>> Thanks,
>> Namhyung

  reply	other threads:[~2016-04-20 15:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14  7:53 [RFC][PATCH v8 0/4] Infrastructure code for perf-config Taeung Song
2016-04-14  7:53 ` [PATCH v8 1/4] perf config: Introduce perf_config_set class Taeung Song
2016-04-14 13:37   ` [tip:perf/core] " tip-bot for Taeung Song
2016-04-14  7:53 ` [PATCH v8 2/4] perf config: Let show_config() work with perf_config_set Taeung Song
2016-04-14 13:37   ` [tip:perf/core] perf config: Make show_config() use perf_config_set tip-bot for Taeung Song
2016-04-14  7:53 ` [PATCH v8 3/4] perf config: Prepare all default configs Taeung Song
2016-04-14 12:19   ` Arnaldo Carvalho de Melo
2016-04-14 16:42     ` Taeung Song
2016-04-18 14:55       ` Taeung Song
2016-04-20 12:44         ` Namhyung Kim
2016-04-20 13:22           ` Arnaldo Carvalho de Melo
2016-04-20 15:29             ` Taeung Song [this message]
2016-04-20 15:11           ` Taeung Song
2016-04-14  7:53 ` [PATCH v8 4/4] perf config: Initialize perf_config_set with " Taeung Song

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=5717A04C.1080403@gmail.com \
    --to=treeze.taeung@gmail.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    /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.