From: Taeung Song <treeze.taeung@gmail.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class
Date: Fri, 1 Apr 2016 19:27:22 +0900 [thread overview]
Message-ID: <56FE4D0A.60200@gmail.com> (raw)
In-Reply-To: <20160331173144.GA10112@kernel.org>
Hi, Arnaldo
Thank you for your review.
On 04/01/2016 02:31 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu:
>> This infrastructure code was designed for
>> upcoming features of perf-config.
>>
>> That collect config key-value pairs from user and
>> system config files (i.e. user wide ~/.perfconfig
>> and system wide $(sysconfdir)/perfconfig)
>> to manage perf's configs.
>>
>> Cc: Namhyung Kim <namhyung@kernel.org>
>> Cc: Jiri Olsa <jolsa@kernel.org>
>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>> ---
>> tools/perf/util/config.c | 171 +++++++++++++++++++++++++++++++++++++++++++++++
>> tools/perf/util/config.h | 26 +++++++
>> 2 files changed, 197 insertions(+)
>> create mode 100644 tools/perf/util/config.h
>>
>> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
>> index 4e72763..2dbf47c 100644
>> --- a/tools/perf/util/config.c
>> +++ b/tools/perf/util/config.c
>> @@ -13,6 +13,7 @@
>> #include <subcmd/exec-cmd.h>
>> #include "util/hist.h" /* perf_hist_config */
>> #include "util/llvm-utils.h" /* perf_llvm_config */
>> +#include "config.h"
>>
>> #define MAXNAME (256)
>>
>> @@ -506,6 +507,176 @@ out:
>> return ret;
>> }
>>
>> +static struct perf_config_section *find_section(struct list_head *sections,
>> + const char *section_name)
>> +{
>> + struct perf_config_section *section;
>> +
>> + list_for_each_entry(section, sections, list)
>> + if (!strcmp(section->name, section_name))
>> + return section;
>> +
>> + return NULL;
>> +}
>> +
>> +static struct perf_config_item *find_config_item(const char *name,
>> + struct perf_config_section *section)
>> +{
>> + struct perf_config_item *config_item;
>> +
>> + list_for_each_entry(config_item, §ion->config_items, list)
>> + if (!strcmp(config_item->name, name))
>> + return config_item;
>> +
>> + return NULL;
>> +}
>> +
>> +static void find_config(struct list_head *sections,
>> + struct perf_config_section **section,
>> + struct perf_config_item **config_item,
>> + const char *section_name, const char *name)
>> +{
>> + *section = find_section(sections, section_name);
>> +
>> + if (*section != NULL)
>> + *config_item = find_config_item(name, *section);
>> + else
>> + *config_item = NULL;
>
>> +}
>> +
>> +static struct perf_config_section *add_section(struct list_head *sections,
>> + const char *section_name)
>> +{
>> + struct perf_config_section *section = zalloc(sizeof(*section));
>> +
>> + if (!section)
>> + return NULL;
>> +
>> + INIT_LIST_HEAD(§ion->config_items);
>> + section->name = strdup(section_name);
>> + if (!section->name) {
>> + pr_err("%s: strdup failed\n", __func__);
>> + free(section);
>> + return NULL;
>> + }
>> +
>> + list_add_tail(§ion->list, sections);
>> + return section;
>> +}
>> +
>> +static struct perf_config_item *add_config_item(struct perf_config_section *section,
>> + const char *name)
>> +{
>> + struct perf_config_item *config_item = zalloc(sizeof(*config_item));
>> +
>> + if (!config_item)
>> + return NULL;
>> +
>> + config_item->name = strdup(name);
>> + if (!name) {
>
> Huh? You're testing the wrong variable.
>
Sorry, my stupid mistake..
>> + pr_err("%s: strdup failed\n", __func__);
>> + goto out_err;
>> + }
>> +
>> + list_add_tail(&config_item->list, §ion->config_items);
>> + return config_item;
>> +
>> +out_err:
>> + free(config_item);
>> + return NULL;
>> +}
>> +
>> +static int set_value(struct perf_config_item *config_item, const char *value)
>> +{
>> + char *val = strdup(value);
>> +
>> + if (!val)
>> + return -1;
>> +
>> + free(config_item->value);
>> + config_item->value = val;
>> + return 0;
>> +}
>> +
>> +static int collect_config(const char *var, const char *value,
>> + void *perf_config_set)
>> +{
>> + int ret = -1;
>> + char *ptr, *key;
>> + char *section_name, *name;
>> + struct perf_config_section *section = NULL;
>> + struct perf_config_item *config_item = NULL;
>> + struct perf_config_set *perf_configs = perf_config_set;
>> + struct list_head *sections = &perf_configs->sections;
>> +
>> + key = ptr = strdup(var);
>> + if (!key) {
>> + pr_err("%s: strdup failed\n", __func__);
>
> pr_debug()
>
I'll change pr_err to pr_debug.
But why do use pr_debug at only this part ?
>> + return -1;
>> + }
>> +
>> + section_name = strsep(&ptr, ".");
>> + name = ptr;
>> + if (name == NULL || value == NULL)
>> + goto out_free;
>> +
>> + find_config(sections, §ion, &config_item, section_name, name);
>
> This idiom is confusing, why not ditch this 'find_config()' function and
> do the searches here? I.e.:
>
> section = find_section(sections, section_name);
I got it.
I think it is needed to remove needless find_config() function as you said.
>> + if (!section) {
>> + section = add_section(sections, section_name);
>> + if (!section)
>> + goto out_free;
>> + }
>
> config_item = find_config_item(name, section);
ok.
>> + if (!config_item) {
>> + config_item = add_config_item(section, name);
>> + if (!config_item)
>> + goto out_free;
>> + }
>> +
>> + ret = set_value(config_item, value);
>> + return ret;
>> +
>> +out_free:
>> + free(key);
>> + perf_config_set__delete(perf_configs);
>> + return -1;
>> +}
>> +
>> +struct perf_config_set *perf_config_set__new(void)
>> +{
>> + struct perf_config_set *perf_configs = zalloc(sizeof(*perf_configs));
>> +
>> + if (!perf_configs)
>> + return NULL;
>> +
>> + INIT_LIST_HEAD(&perf_configs->sections);
>> + perf_config(collect_config, perf_configs);
>> +
>> + return perf_configs;
>> +}
>
> Usually for these short functions we could do it more compactly as:
>
> struct perf_config_set *perf_config_set__new(void)
> {
> struct perf_config_set *perf_configs = zalloc(sizeof(*perf_configs));
>
> if (perf_configs) {
> INIT_LIST_HEAD(&perf_configs->sections);
> perf_config(collect_config, perf_configs);
> }
>
> return perf_configs;
> }
>
> But I'm not dwelling on this...
>
I got it, too!
>> +void perf_config_set__delete(struct perf_config_set *perf_configs)
>> +{
>> + struct perf_config_section *section, *section_tmp;
>> + struct perf_config_item *config_item, *item_tmp;
>> +
>> + list_for_each_entry_safe(section, section_tmp,
>> + &perf_configs->sections, list) {
>> + list_for_each_entry_safe(config_item, item_tmp,
>> + §ion->config_items, list) {
>> + list_del(&config_item->list);
>> + free(config_item->name);
>> + free(config_item->value);
>> + free(config_item);
>> + }
>> + list_del(§ion->list);
>> + free(section->name);
>> + free(section);
>> + }
>> +
>> + free(perf_configs);
>> +}
>
> What is the problem with having perf_config_item__delete() and
> perf_config_section__delete() and then have it like below, also please
> rename those foo->list to foo->node.
>
No problem!
OK, I'll rename it.
> void perf_config_item__delete(struct perf_config_item *item)
> {
> zfree(&item->name);
> zfree(&item->value);
> free(item);
> }
>
> void perf_config_section__purge(struct perf_config_section *section)
> {
> struct perf_config_item *item, *tmp;
>
> list_for_each_entry_safe(item, tmp, §ion->items, node) {
> list_del_init(&item->node);
> perf_config_item__delete(item);
> }
> }
>
> void perf_config_section__delete(struct perf_config_section *section)
> {
> perf_config_section__purge(section);
> zfree(§ion->name);
> free(section);
> }
>
> void perf_config_set__purge(struct perf_config_set *set)
> {
> struct perf_config_section *section, *tmp;
>
> list_for_each_entry_safe(section, tmp, &set->sections, node) {
> list_del_init(§ion->node);
> perf_config_section__delete(section);
> }
> }
>
> void perf_config_set__delete(struct perf_config_set *set)
> {
> perf_config_set__purge(set);
> free(set);
> }
>
> Using zfree() and list_del_init to NULL or poison the freed pointers
> helps with debugging, please use them.
ok.
>
>> +
>> /*
>> * Call this to report error for your variable that should not
>> * get a boolean value (i.e. "[my] var" means "true").
>> diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
>> new file mode 100644
>> index 0000000..e270e51
>> --- /dev/null
>> +++ b/tools/perf/util/config.h
>> @@ -0,0 +1,26 @@
>> +#ifndef __PERF_CONFIG_H
>> +#define __PERF_CONFIG_H
>> +
>> +#include <stdbool.h>
>> +#include <linux/list.h>
>> +
>> +struct perf_config_item {
>> + char *name;
>> + char *value;
>> + struct list_head list;
>
> s/list/node/g
>
>> +};
>> +
>> +struct perf_config_section {
>> + char *name;
>> + struct list_head config_items;
>
> s/config_items/items/g
>
>> + struct list_head list;
>
> s/list/node/g
>> +};
>> +
>> +struct perf_config_set {
>> + struct list_head sections;
>
> See? Here you did it right, no point in having it as "config_sections"
>
I'll rename it to 'config_sections'.
>> +};
>> +
>> +struct perf_config_set *perf_config_set__new(void);
>> +void perf_config_set__delete(struct perf_config_set *perf_configs);
>
> void perf_config_set__delete(struct perf_config_set *set);
>
OK, I'll use 'set' variable name instead of perf_configs on this source
file.
I'll resend this patch after modifying what you said. :-)
Thanks,
Taeung
>> +
>> +#endif /* __PERF_CONFIG_H */
>> --
>> 2.5.0
next prev parent reply other threads:[~2016-04-01 10:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 0:43 [PATCH v4 1/4] perf config: Introduce perf_config_set class Taeung Song
2016-03-29 16:12 ` Arnaldo Carvalho de Melo
2016-03-29 23:28 ` Taeung Song
2016-03-30 2:09 ` Namhyung Kim
2016-03-30 11:04 ` Taeung Song
2016-03-31 17:31 ` Arnaldo Carvalho de Melo
2016-04-01 10:27 ` Taeung Song [this message]
2016-04-01 14:35 ` Arnaldo Carvalho de Melo
2016-04-02 11:58 ` 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=56FE4D0A.60200@gmail.com \
--to=treeze.taeung@gmail.com \
--cc=arnaldo.melo@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.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.