[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191126094508.GB32367@krava>
Date: Tue, 26 Nov 2019 10:45:08 +0100
From: Jiri Olsa <jolsa@...hat.com>
To: Changbin Du <changbin.du@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/2] perf: support multiple debug options separated by
','
On Mon, Nov 25, 2019 at 11:14:45PM +0800, Changbin Du wrote:
> This patch adds support for multiple debug options separated by ',' and
> non-int values.
> --debug verbose=2,stderr
>
> Signed-off-by: Changbin Du <changbin.du@...il.com>
> ---
> tools/perf/Documentation/perf.txt | 13 +++--
> tools/perf/util/debug.c | 89 ++++++++++++++++---------------
> 2 files changed, 53 insertions(+), 49 deletions(-)
>
> diff --git a/tools/perf/Documentation/perf.txt b/tools/perf/Documentation/perf.txt
> index 3f37ded13f8c..fd8d790f68a7 100644
> --- a/tools/perf/Documentation/perf.txt
> +++ b/tools/perf/Documentation/perf.txt
> @@ -19,13 +19,12 @@ OPTIONS
> --debug verbose=2 # sets verbose = 2
>
> List of debug variables allowed to set:
> - verbose - general debug messages
> - ordered-events - ordered events object debug messages
> - data-convert - data convert command debug messages
> - stderr - write debug output (option -v) to stderr
> - in browser mode
> - perf-event-open - Print perf_event_open() arguments and
> - return value
> + verbose=level - general debug messages
> + ordered-events=level - ordered events object debug messages
> + data-convert=level - data convert command debug messages
> + stderr - write debug output (option -v) to stderr
> + perf-event-open - Print perf_event_open() arguments and
> + return value in browser mode
it's just the list and the doc says user can use values
there, so no need for the '=level' there
also we allow this:
perf --debug stderr=9 record ls
so I thinks we should keep it general in documentation,
eventhough it will always mean just stderr=true for any
value
jirka
Powered by blists - more mailing lists