public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung.kim@lge.com>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>
Subject: Re: [RFC PATCHSET] perf ui: Small preparation on further UI work
Date: Thu, 29 Mar 2012 10:03:53 +0900	[thread overview]
Message-ID: <87obrgcj5y.fsf@youngshil.aot.lge.com> (raw)
In-Reply-To: <20120328142808.GA8482@infradead.org> (Arnaldo Carvalho de Melo's message of "Wed, 28 Mar 2012 11:28:08 -0300")

Hi,

On Wed, 28 Mar 2012 11:28:08 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 28, 2012 at 11:14:25AM +0900, Namhyung Kim escreveu:
>> Em Tue, Mar 27, 2012 at 01:44:42PM +0300, Pekka Enberg escreveu: 
>> > Arnaldo Carvalho de Melo <acme@ghostprotocols.net> wrote:
>
>> > 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
>
> What do you have against directory trees? :P We need to chop off the
> /util/ part, but apart from that...
>
>> 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.
>
> ... what is the difference of using:
>
> tools/perf/util/ui/tui/init.c
>
> instead of:
>
> tools/perf/util/ui/tui-init.c
>
> ?
>

Nothing. I just want to remain the directory nesting level if you care. :)


> Since we'll be introducing new files, it seems the first step would be
> to just do a simple, no changes in the files, move of
> tools/perf/util/ui/ to tools/perf/ui/ and then introduce
> tools/perf/ui/tui/{init,etc}.c
>
> Gtk would as well be moved to tools/perf/ui/gtk/.
>

Yeah, This is what I wanted to have from the begining. I'll revise my
patches after moving the files to tools/perf/ui.

> At some point we would then introduce some sort of plugin mechanism
> where files found in /usr/lib/perf/ui/ or some other suitable directory
> would be loaded in a modprobe like way, i.e. if the user asks for --gtk,
> it would try to find /usr/lib/perf/ui/gtk.so and try to load it, etc.
>
> That way we start to reduce the miriad libraries that we have linked in
> the main perf binary, making it easier for packaging, etc.
>
> - Arnaldo

That would be great!

Thanks,
Namhyung

      reply	other threads:[~2012-03-29  1:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26  8:51 [RFC PATCHSET] perf ui: Small preparation on further UI work Namhyung Kim
2012-03-26  8:51 ` [PATCH 1/5] perf ui: Make setup_browser() generic Namhyung Kim
2012-03-26  8:51 ` [PATCH 2/5] perf ui: Drop arg[cv] arguments from perf_gtk_setup_browser() Namhyung Kim
2012-03-26  8:51 ` [PATCH 3/5] perf ui: Add gtk2 support into setup_browser() Namhyung Kim
2012-03-26  8:51 ` [PATCH 4/5] perf gtk: Rename functions for consistency Namhyung Kim
2012-03-26  8:51 ` [PATCH 5/5] perf ui: Change fallback policy of setup_browser() Namhyung Kim
2012-03-26  9:46 ` [RFC PATCHSET] perf ui: Small preparation on further UI work Pekka Enberg
2012-03-26 17:38 ` Arnaldo Carvalho de Melo
2012-03-27 10:44   ` Pekka Enberg
2012-03-27 13:55     ` Arnaldo Carvalho de Melo
2012-03-28  2:14   ` Namhyung Kim
2012-03-28 14:28     ` Arnaldo Carvalho de Melo
2012-03-29  1:03       ` Namhyung Kim [this message]

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=87obrgcj5y.fsf@youngshil.aot.lge.com \
    --to=namhyung.kim@lge.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=penberg@kernel.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