Em Sat, Feb 24, 2018 at 09:40:02AM +0800, Jin, Yao escreveu: > > > On 2/23/2018 11:29 PM, Arnaldo Carvalho de Melo wrote: > > Em Fri, Feb 23, 2018 at 09:25:00AM +0100, Peter Zijlstra escreveu: > > > On Fri, Feb 23, 2018 at 10:35:58PM +0800, Jin Yao wrote: > > > > Unlike the perf report interactive annotate mode, the perf annotate > > > > doesn't display the LBR data. > > > > > > perf record -b ... > > > > perf annotate function > > > > > > It should show IPC/cycle, but it doesn't. > > > > > There is far more than IPC/cycle for the LBR data, so this Changelog is > > > misleading. > > > > > Also, I think that this patch goes the wrong way, we should reduce the > > > divergence of the various modes, not make it worse. > > > > Right, Peter, what would you think if I made --stdio use the same > > routines used to format the TUI, i.e. stdio would be equal to the TUI > > modulo de navigation/jump arrows, etc. > > > > We would have switches to provide the TUI output options that make sense > > for non-interactive mode, like: > > > > J Toggle showing number of jump sources on targets > > o Toggle disassembler output/simplified view > > s Toggle source code view > > t Circulate percent, total period, samples view > > k Toggle line numbers > > > > Hi Arnaldo, looks your idea is very similar as my idea. In my understanding, > for example, we may provide switch to tui routine like > annotate_browser__write() and use fprintf() to replace > ui_browser__printf()/ui_browser_write__xxx() if switch is on for stdio. > > Is that your idea?
Yes, right now the TUI simply uses foo__scnprintf() routines to then pass formatted buffers to the TUI routines, we would then just pass them to plain fprintf(sdtout). > For this approach, I think, the benefit is we can reuse most of existing > code but the disadvantage is we have to mix tui and stdio up. - Arnaldo
