From: Ingo Molnar <mingo@elte.hu>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Avi Kivity <avi@redhat.com>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>,
Mike Galbraith <efault@gmx.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH v2 5/5] perf report: Initial TUI using newt
Date: Fri, 12 Mar 2010 10:45:33 +0100 [thread overview]
Message-ID: <20100312094533.GA13177@elte.hu> (raw)
In-Reply-To: <1268349164-5822-5-git-send-email-acme@infradead.org>
* Arnaldo Carvalho de Melo <acme@infradead.org> wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> Newt has widespread availability and provides a rather simple API as can be
> seen by the size of this patch.
>
> The work needed to support it will benefit other frontends too.
>
> In this initial patch it just checks if the output is a tty, if not it falls
> back to the previous behaviour, also if newt-devel/libnewt-dev is not
> installed the previous behaviour is maintaned.
>
> Pressing enter on a symbol will annotate it, ESC in the annotation window will
> return to the report symbol list.
Very nice!
a few observations. Firstly, could we perhaps make most of the interface
functions GUI/TUI invariant? I.e. things like:
> + if (use_browser)
> + r = vfprintf(fp, fmt, args);
> + else
> + r = color_vfprintf(fp, color, fmt, args);
should be abstracted away into a single method:
r = color_vprintf(fp, color, fmt, args);
where color_vprintf() knows about which current GUI front-end to use.
(The old color_printf() should be renamed to ascii_color_printf() or so, and
put into a front-end driver structure perhaps - instead of explicit flags.)
There's a similar situation here too:
> - ret = vfprintf(stderr, fmt, args);
> + if (use_browser)
> + ret = browser__show_help(fmt, args);
> + else
> + ret = vfprintf(stderr, fmt, args);
Plus a few other observations about the newt TUI itself:
- The most important first-impression thing in a TUI is to make it obvious to
exit it. I eventually found that Escape would exit - but it would be nice
to map 'Q' and 'Ctrl-C' to it as well. Nothing is more annoying than a TUI
you cannot exit from.
- There's still a 'perf annotate' bug that has been introduced recently, and
it shows up in the TUI too. The bug is due to us passing this to objdump
and grep:
18573 execve("/bin/sh", ["sh", "-c", "objdump --start-address=0xffffffff81387b36
--stop-address=0xffffffff81387b4f -dS [kernel.kallsyms]|grep -v [kernel.kallsyms]"]
Look at how [kernel.kallsyms] goes unquoted to the shell, so globbing will
match it on random file names in the current directory - which will then be
showed by objdump, much to the surprise of the user!
- I suspect we should finally make use of the .perfconfig parser and enable people
to use a different front-end from Newt? Just in case they prefer ASCII.
- When i hit enter on a symbol to annotate it, but the annotation fails, the TUI
just does nothing currently. Instead it should print something informative
(and eye-catching) into a status line at the top or the bottom of the
screen, possibly printed in red characters or so. Not a separate window as that
needs extra key-hits to get rid of - just a sufficiently visible status
line would be perfect. There can be a few reasons why some functions can be
annotated while others cannot be.
- [ call-graph data is not represented yet :-) ]
Anyway, very nice stuff!
Ingo
next prev parent reply other threads:[~2010-03-12 9:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-11 23:12 [PATCH v2 1/5] perf symbols: Bump plt synthesizing warning debug level Arnaldo Carvalho de Melo
2010-03-11 23:12 ` [PATCH v2 2/5] perf top: Export get_window_dimensions Arnaldo Carvalho de Melo
2010-03-11 23:12 ` [PATCH v2 3/5] perf tools: Use eprintf for pr_{err,warning,info} too Arnaldo Carvalho de Melo
2010-03-11 23:12 ` [PATCH v2 4/5] perf tools: Add missing bytes printed in hist_entry__fprintf Arnaldo Carvalho de Melo
2010-03-11 23:12 ` [PATCH v2 5/5] perf report: Initial TUI using newt Arnaldo Carvalho de Melo
2010-03-11 23:29 ` Arnaldo Carvalho de Melo
2010-03-12 5:43 ` Frederic Weisbecker
2010-03-12 8:21 ` Avi Kivity
2010-03-12 6:48 ` Mike Galbraith
[not found] ` <1268377317.24910.1.camel@marge.simson.net>
2010-03-12 13:56 ` Arnaldo Carvalho de Melo
2010-03-12 9:45 ` Ingo Molnar [this message]
2010-03-12 9:55 ` Avi Kivity
2010-03-12 13:27 ` Arnaldo Carvalho de Melo
2010-03-12 13:25 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100312094533.GA13177@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=acme@redhat.com \
--cc=avi@redhat.com \
--cc=efault@gmx.de \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox