All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.