Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752789AbcCLIrQ (ORCPT ); Sat, 12 Mar 2016 03:47:16 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:33622 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbcCLIrH (ORCPT ); Sat, 12 Mar 2016 03:47:07 -0500 Date: Sat, 12 Mar 2016 17:45:41 +0900 From: Namhyung Kim To: Taeung Song Cc: Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Jiri Olsa , Ingo Molnar , Peter Zijlstra Subject: Re: [RFC][PATCH] perf config: Introduce perf_config_set class Message-ID: <20160312084541.GB27257@danjae.kornet> References: <1457618667-19915-1-git-send-email-treeze.taeung@gmail.com> <20160311141131.GB25533@danjae.kornet> <56E2DF84.7080406@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56E2DF84.7080406@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2712 Lines: 100 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