Re: [RFC/PATCH 0/4] perf report: Support folded callchain output (v2)

[Arnaldo Carvalho de Melo]

Em Tue, Nov 03, 2015 at 10:35:35AM +0900, Namhyung Kim escreveu:
> On Mon, Nov 02, 2015 at 09:46:47PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Nov 03, 2015 at 08:46:06AM +0900, Namhyung Kim escreveu:
> > > On Mon, Nov 02, 2015 at 08:04:36PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > I still think that this is a 'perf report' thing, but one that is
> > > > centered in callchains, and that is to be consumed by scripts, not
> > > > humans.
> >  
> > > Agreed.
> >  
> > > I'm just looking for a way to support it with minimal change. :)
> > 
> > Hey, me too. A --no-hists flag looks like a quickie, no need to isolate
> > callchain code, or anything like that, just one long option switch and
> > we get what we need.
> 
> Hmm.. okay.  Let me think about the --no-hists flags then.
> 
> What do you want to do if the --no-hists flags is used without folded
> callchain mode or other than --stdio?

What the user asked it to, to not show what hist_entry__snprintf()
produces, i.e. just the callchains.

Its left to the user to decide if that output is good for whatever
purpose it has in mind.

We, from this discussion, know that suppressing it when using with
folded callchains, is useful at least for Brendan's scripts :-)
 
> And if you want to print other info in the callchains, what would be
> the output of non-folded mode?
 
> I think the simplest solution would be supporting the folded mode only
> and error out other cases.  Is it ok to you?

Well, the other info, if it comes at the end, may even be useful in non
folded mode, no?

If it is not, then the user will not use it, i.e. some combinations may
not produce useful results, but if we want to have more flexibility to
support usecases like Brendan's, and I think we want, without making the
existing code overly complex, then why not?

- 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/