Re: [PATCH 3/3] perf report: Add --show-time-info option

[Arnaldo Carvalho de Melo]

Em Wed, Dec 04, 2013 at 11:11:17AM +0100, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/