Hi, Namhyung

On 03/17/2016 09:31 PM, Namhyung Kim wrote:
Hi Taeung,

On Mon, Mar 14, 2016 at 09:16:05PM +0900, Taeung Song wrote:
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 <namhy...@kernel.org>
Cc: Jiri Olsa <jo...@kernel.org>
Signed-off-by: Taeung Song <treeze.tae...@gmail.com>
---
  tools/perf/builtin-config.c |   1 +
  tools/perf/util/config.c    | 123 ++++++++++++++++++++++++++++++++++++++++++++
  tools/perf/util/config.h    |  21 ++++++++
  3 files changed, 145 insertions(+)
  create mode 100644 tools/perf/util/config.h

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index c42448e..412c725 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -12,6 +12,7 @@
  #include <subcmd/parse-options.h>
  #include "util/util.h"
  #include "util/debug.h"
+#include "util/config.h"

  static bool use_system_config, use_user_config;

diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 4e72763..b9660e4 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,128 @@ out:
        return ret;
  }

+static struct perf_config_item *find_config(struct list_head *config_list,
+                                      const char *section,
+                                      const char *name)
+{
+       struct perf_config_item *config;
+
+       list_for_each_entry(config, config_list, list) {
+               if (!strcmp(config->section, section) &&
+                   !strcmp(config->name, name))
+                       return config;
+       }

Hmm.. why do you remove the section list?


IMHO, there are several reasons

    1) To use only one list (default config, custom config(user/system))

1-1) I used two list that were 'list_head sections'
and 'config_item default_configs[]'. So if checking
type of config variable, two for-loop must be needed
for each list. Because two structure was different i.e.

'sections' list mean config_section list
that each section contain config_element list.
(there wasn't telling about correct type of 'value' instead of string(char *))

    struct config_element {
            char *name;
            char *value;
            struct list_head list;
    };

    struct config_section {
            char *name;
            struct list_head element_head;
            struct list_head list;
    };

'struct config_item default_configs[]' mean all default configs.

    struct config_item {
            const char *section;
            const char *name;
            union {
                bool b;
                int i;
                u32 l;
                u64 ll;
                float f;
                double d;
                const char *s;
            } value;
            enum config_type type;
            const char *desc;
    };


IMHO, I think this is a bit complex
and I want to simplify the perf's config list on perf-config.

    2) A small number of perf's configs

I think perf's configs aren't too many so I think
two structure for section and element aren't needed.

    3) A object for a config variable need to have enough info for itself

This is a bit similar to 1) reason.
If using only 'struct config_item' for the config list,
it can contain section name, name, values(default, user config,
system config, both config), correct type, etc.

If we do, we needn't to find detail for a config variable at other objects e.g.
When we find correct type of a config variable,
we needn't to do for-loop for default_configs[] in order to know the type.


I think this is better than old two structure.

+
+       return NULL;
+}
+
+static struct perf_config_item *add_config(struct list_head *config_list,
+                                          const char *section,
+                                          const char *name)
+{
+       struct perf_config_item *config = zalloc(sizeof(*config));
+
+       if (!config)
+               return NULL;
+
+       config->section = strdup(section);
+       if (!section)
+               goto out_err;
+
+       config->name = strdup(name);
+       if (!name) {
+               free((char *)config->section);
+               goto out_err;
+       }
+
+       list_add_tail(&config->list, config_list);
+       return config;
+
+out_err:
+       free(config);
+       pr_err("%s: strdup failed\n", __func__);
+       return NULL;
+}
+
+static int set_value(struct perf_config_item *config, const char *value)
+{
+       char *val = strdup(value);
+
+       if (!val)
+               return -1;
+       config->value = val;

It seems to overwrite old value..


Yes, I know it.
If don't using '--user' or '--system',
there isn't exclusive config file path
then have to read both config files.

But because user config file has a high order of priority,
if two config file has same variable, old value(for system config)
must be overwrote by new value(for user config).


Thanks,
Taeung



+
+       return 0;
+}
+
+static int collect_config(const char *var, const char *value,
+                         void *configs)
+{
+       int ret = 0;
+       char *ptr, *key;
+       char *section, *name;
+       struct perf_config_item *config;
+       struct list_head *config_list = configs;
+
+       key = ptr = strdup(var);
+       if (!key) {
+               pr_err("%s: strdup failed\n", __func__);
+               return -1;
+       }
+
+       section = strsep(&ptr, ".");
+       name = ptr;
+       if (name == NULL || value == NULL) {
+               ret = -1;
+               goto out_free;
+       }
+
+       config = find_config(config_list, section, name);
+       if (!config) {
+               config = add_config(config_list, section, name);
+               if (!config) {
+                       free(config->section);
+                       free(config->name);
+                       ret = -1;
+                       goto out_free;
+               }
+       }
+
+       ret = set_value(config, value);
+
+out_free:
+       free(key);
+       return ret;
+}
+
+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->config_list);
+       perf_config(collect_config, &perf_configs->config_list);
+
+       return perf_configs;
+}
+
+void perf_config_set__delete(struct perf_config_set *perf_configs)
+{
+       struct perf_config_item *pos, *item;
+
+       list_for_each_entry_safe(pos, item, &perf_configs->config_list, list) {
+               list_del(&pos->list);
+               free(pos->section);
+               free(pos->name);
+               free(pos->value);
+               free(pos);
+       }
+
+       free(perf_configs);
+}
+
  /*
   * 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..44c226f
--- /dev/null
+++ b/tools/perf/util/config.h
@@ -0,0 +1,21 @@
+#ifndef __PERF_CONFIG_H
+#define __PERF_CONFIG_H
+
+#include <stdbool.h>
+#include <linux/list.h>
+
+struct perf_config_item {
+       char *section;
+       char *name;
+       char *value;
+       struct list_head list;
+};
+
+struct perf_config_set {
+       struct list_head config_list;
+};
+
+struct perf_config_set *perf_config_set__new(void);
+void perf_config_set__delete(struct perf_config_set *perf_configs);
+
+#endif /* __PERF_CONFIG_H */
--
2.5.0

Reply via email to