All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Taeung Song <treeze.taeung@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: Thu, 31 Mar 2016 14:31:44 -0300	[thread overview]
Message-ID: <20160331173144.GA10112@kernel.org> (raw)
In-Reply-To: <1459212193-1095-1-git-send-email-treeze.taeung@gmail.com>

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, &section->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(&section->config_items);
> +	section->name = strdup(section_name);
> +	if (!section->name) {
> +		pr_err("%s: strdup failed\n", __func__);
> +		free(section);
> +		return NULL;
> +	}
> +
> +	list_add_tail(&section->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.

> +		pr_err("%s: strdup failed\n", __func__);
> +		goto out_err;
> +	}
> +
> +	list_add_tail(&config_item->list, &section->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()

> +		return -1;
> +	}
> +
> +	section_name = strsep(&ptr, ".");
> +	name = ptr;
> +	if (name == NULL || value == NULL)
> +		goto out_free;
> +
> +	find_config(sections, &section, &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);
> +	if (!section) {
> +		section = add_section(sections, section_name);
> +		if (!section)
> +			goto out_free;
> +	}

 	config_item = find_config_item(name, section);
> +	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...

> +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,
> +					 &section->config_items, list) {
> +			list_del(&config_item->list);
> +			free(config_item->name);
> +			free(config_item->value);
> +			free(config_item);
> +		}
> +		list_del(&section->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.

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, &section->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(&section->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(&section->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.

> +
>  /*
>   * 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"

> +};
> +
> +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);

> +
> +#endif /* __PERF_CONFIG_H */
> -- 
> 2.5.0

  parent reply	other threads:[~2016-03-31 17:31 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 [this message]
2016-04-01 10:27   ` Taeung Song
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=20160331173144.GA10112@kernel.org \
    --to=acme@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=treeze.taeung@gmail.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.