Messages in this thread | | | Date | Wed, 4 Dec 2013 09:57:03 -0300 | From | Arnaldo Carvalho de Melo <> | Subject | Re: [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
| |