linux-kernel - Re: [RFC PATCHSET] perf ui: Small preparation on further UI work

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Mar 2012 14:38:17 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Namhyung Kim <namhyung.kim@....com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	Namhyung Kim <namhyung@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...nel.org>
Subject: Re: [RFC PATCHSET] perf ui: Small preparation on further UI work

Em Mon, Mar 26, 2012 at 05:51:31PM +0900, Namhyung Kim escreveu:
> This is my initial work of UI generalization. As we now get GTK2 support on
> perf report, improve setup_browser() to handle it properly so that we can
> add various UI specific initialization codes to the function. At least, we
> need basic error/warning handlers ASAP to see what's going on when an error
> occurred, IMHO.
> 
> I put new file setup.c under ui directory (not under util/ui) and it may or
> may not be compiled depending on the system configuration. I think it'd be
> better moving generic UI codes to the directory and TUI specific codes to
> ui/tui, and so on, so that the util directory doesn't contain any UI codes.
> But before proceeding, I'd like to listen to your opinions :).

My plans were for util/ui/ to be this generalization you want to, hence
I didn't use the 't', i.e. I didn't call it util/tui/, because tui would
be just one of the possible backends.

But that still needs more work that I haven't be able to pursue. Pekka
thinks that doing it that way is not OK as it would limit what one could
do with a more featureful UI like GTK+.

I would like to still pursue a simple GUI using a function table for
the simple operations we use in the hists browser in
tools/perf/util/ui/ but if others want to pursue it the way the GTK+
browser is being worked on, more power to them.

So I would just leave things in tools/perf/util/ui/ and do what you did
in moving the TUI specific bits to a separate function, even ui__init()
would be ok for now, and then at setup_browser() check what kind of
interface is being used and call ui__init() if it is the TUI and the
gtk init one if GTK+ was chosen.

But wouldn't introduce tools/perf/ui/setup.c for that, no need for new
directory trees, I think :-)

- Arnaldo
 
> Any comments are welcome.
> Thanks.
> 
> Namhyung Kim (5):
>   perf ui: Make setup_browser() generic
>   perf ui: Drop arg[cv] arguments from perf_gtk_setup_browser()
>   perf ui: Add gtk2 support into setup_browser()
>   perf gtk: Rename functions for consistency
>   perf ui: Change fallback policy of setup_browser()
> 
>  tools/perf/Makefile           |    7 ++++-
>  tools/perf/builtin-report.c   |    5 +---
>  tools/perf/ui/setup.c         |   44 +++++++++++++++++++++++++++++
>  tools/perf/util/cache.h       |   24 +++++++++++-----
>  tools/perf/util/gtk/browser.c |   27 +++++++++---------
>  tools/perf/util/gtk/gtk.h     |    4 +++
>  tools/perf/util/ui/setup.c    |   61 +++++++++++++++-------------------------
>  7 files changed, 108 insertions(+), 64 deletions(-)
>  create mode 100644 tools/perf/ui/setup.c
> 
> -- 
> 1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/