lkml.org 
[lkml]   [2013]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] perf report: Add --show-time-info option
Em Wed, Dec 04, 2013 at 11:11:17AM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@ghostprotocols.net> wrote:
> > Em Mon, Dec 02, 2013 at 12:58:35PM -0700, David Ahern escreveu:
> > > On 12/2/13, 12:38 PM, Arnaldo Carvalho de Melo wrote:
> > > Why not just --event-time?

> > > Really should have dropped the 'show' from the recent perf-script
> > > change (just --task-events and --mmap-events).

> > Probably, yeah, Ingo made some point about using --show- for some reason,
> > Ingo?

> So the reason for my suggestion was that I've noticed a proliferation
> of such flags in perf report. To reduce namespace pollution it's
> always good to bring a certain kind of hierarchy into command line
> options.

> Options that work alike should spell alike. Users shouldn't be
> required to memorize every naming quirk of the various disjunct
> 'display this extra data' options.

> So if we expect more --show options in the future (and in particular
> if there are existing oddball options that could be changed to the
> --show-xyz pattern) then I'd suggest to do it unified. For example
> there's --show-nr-samples and --show-info already which follows this
> pattern.

> This pattern would distinguish this option from the other perf report
> options, such as --vmlinux, --force, --sort, etc.

> It might even make sense to unify it all into a single --show option.
> That would allow the following current mismash of options:

> --task-events --mmap-events --show-nr-samples --show-info

> to be replaced by a much more obvious, much more coherent looking
> option sequence:

> --show task-events,mmap-events,nr-samples,info

Excellent idea, agreed, we should probably try to implement this as a
generic facility to be used accross all the tools.

This, together with the other options processing code should be a
natural candidate for a tools/lib/opt/ directory, implemented in the way
we discussed: a .a for tools that want all the options processing, but
also as untangled as possible so that tools that want just specific bits
can chew them individually.

So, in summary, we _will_ be dropping the 'show-' prefix from all those
options, and those options as well, that then just become a single (top
level) option with entries in a bitmask that are set via some OPT_
callback that receives some struct with a string table and has a bitmask
that it will set.

> an added bonus would be that '--show help' could be implemented as
> well, to list all displayable extra data.

Right, the string table I mentioned in fact should be a struct table
that in turn has two strings, the --show bitname and bithelp.

> (I'm not married to the specific naming, it could be something else as
> well, like --display or --report.)

I think 'show' is ok, 4 letters, shorter than 'display', already used in
several places.

- Arnaldo


\
 
 \ /
  Last update: 2013-12-04 14:41    [W:0.160 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site