| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <56EABAC4.107@gmail.com>
Date: Thu, 17 Mar 2016 23:10:12 +0900
From: Taeung Song <treeze.taeung@...il.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org, Jiri Olsa <jolsa@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 1/5] perf config: Introduce perf_config_set class
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 <namhyung@...nel.org>
>> Cc: Jiri Olsa <jolsa@...nel.org>
>> Signed-off-by: Taeung Song <treeze.taeung@...il.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
>>
Powered by blists - more mailing lists