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]

Message-ID: <87pqbx320u.fsf@youngshil.aot.lge.com>
Date:	Wed, 28 Mar 2012 11:14:25 +0900
From:	Namhyung Kim <namhyung.kim@....com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...nel.org>
Subject: Re: [RFC PATCHSET] perf ui: Small preparation on further UI work

Hi,

Arnaldo Carvalho de Melo <acme@...stprotocols.net> wrote:

> 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.
>

Yeah, I was thinking about it too. I think the warning/error reporting
utilties seem to fit for that direction.


> 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.
>

I think it'd be better moving the TUI specific codes to a separate file
(under a separate directory, like tools/perf/util/ui/tui - but it looks
like so deep nesting) rather than a function since the generic
code (setup_browser) should be compiled without the TUI support.
Otherwise we'll see some #ifdef's in the source file(s).

Or, we can put those codes under the same directory (tools/perf/util/ui)
and have different suffixes - say, if generic code were XXX.c, TUI one
would be XXX-tui.c and GTK+ one would be XXX-gtk.c.


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

OK.

Thanks,
Namhyung
--
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/