On 03/07/2010 08:53 PM, Arnaldo Carvalho de Melo wrote:
Do you really think that more kernel developers would use perf more
frequently if it had some GUI?
Not much. Is perf's target kernel developers exclusively? Who are
we writing this kernel for?
No, we aren't writing this tool only for kernel developers exclusively,
but that wasn't my question, it was badly formulated, sorry, I shouldn't
have included "kernel" in it :-\
In this case, I will reformulate my answer. Very much.
Even for kernel developers there are advantages in a GUI, namely
that features are easily discovered, the amount of information is
easily controlled, and in that you can interact (not redo everything
from scratch every time you want to change something). The
difference between a curses based tool and a true GUI are minimal
for this audience.
Ok, I agree with you about easier discoverability of features, path
shortened from report to annotate to starting the editor right at the
line where some event of interest happened,
Another path is browse some function, start profiling, see perf data
fill up in the margin. Or, jump to callers. etc. You need an
integrated browser for that (or an emacs perf mode).
will try to keep the
routines not much coupled with ncurses, but definetely ncurses will be
the first step.
Great. ncurses is certainly much easier to experiment with and will
likely provide useful experience.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
