linux-kernel - Re: [RFC][PATCH] perf config: Introduce perf_config

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160312084541.GB27257@danjae.kornet>
Date:	Sat, 12 Mar 2016 17:45:41 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Taeung Song <treeze.taeung@...il.com>
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: [RFC][PATCH] perf config: Introduce perf_config_set class

Hi Taeung,

On Sat, Mar 12, 2016 at 12:08:52AM +0900, Taeung Song wrote:
> Hi, Namhyung
> 
> On 03/11/2016 11:11 PM, Namhyung Kim wrote:
> >Also I think it'd be better just keeping a single config value instead
> >of 3 kinds.  Maybe you can read system-wide config first and overwrite
> >them with user config (for the 'both' case).
> >
> 
> I know what you mean. I agonized about it.
> 
> IMHO, I think that if keeping a single config value instead of 3 kinds and
> perf-config has setting functionality when writing a changed config
> on a specific config file, some problems can occur e.g.

Do you plan to support 'set' and 'get' operation at the same time?
IOW is it possible to do?

  $ perf config --set aaa.bbb=xx --get ccc.ddd

I don't think it's very useful.

If we don't do it, I think we can simply read a single config file
(default to user file) and re-write it for the 'set' operation.

Or maybe we can add a field (like 'origin'?) in the perf_config_item
struct to mark where it comes from.  And then it should write items
matching 'origin' only.

Thanks,
Namhyung


> 
> (Because setting functionality I design is that overwrite
> a specific config file by the perf config list)
> (the perf config list : all perf configs from the config files)
> 
> User wide:
> 
>     # cat ~/.perfconfig
>     [report]
>         queue-size = 1
>     [test]
>         location = user
> 
> System wide:
> 
>     # cat /usr/local/etc/perfconfig
>     [ui]
>         show-headers = false
>     [test]
>         location = system
> 
> And if perf-config has setting functionality,
> 
>     # perf config --system top.children=false
> 
> We hoped for:
> 
>     # cat /usr/local/etc/perfconfig
>     [ui]
>         show-headers = false
>     [test]
>         location = system
>     [top]
>         children = false
> 
> But actual result can be:
> 
>     # cat /usr/local/etc/perfconfig
>     [ui]
>         show-headers = false
>     [report]
>         queue-size = 1
>     [test]
>         location = user
>     [top]
>         children = false
> 
> We wouldn't want that system config file contain contents of
> user config file.
> The reason of this problem is that setting functionality I design
> work with perf config list overwriting a specific config file
> and if perf config list has only single value each config,
> we don't exactly know old values of system config.
> 
> Don't design setting functionality that overwrite by perf config list ?
> (writing '# this file is auto-generated.' at the top of config file)
> 
> Add a changed config into a specific config file by other way ? :-\
> 
> Or
> Not now, when add setting functionality into perf-config,
> consider this problem ?
> 
> Thanks,
> Taeung