public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: David Ahern <daahern@cisco.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH 07/10] perf script: Move printing of 'common' data from print_event and rename
Date: Thu, 10 Mar 2011 01:50:03 +0100	[thread overview]
Message-ID: <20110310005001.GF2533@nowhere> (raw)
In-Reply-To: <4D781C16.3080706@cisco.com>

On Wed, Mar 09, 2011 at 05:32:22PM -0700, David Ahern wrote:
> 
> 
> On 03/09/11 17:22, Frederic Weisbecker wrote:
> > On Wed, Mar 09, 2011 at 05:15:00PM -0700, David Ahern wrote:
> >>
> >>
> >> On 03/09/11 17:10, Frederic Weisbecker wrote:
> >>>
> >>> And if you actually keep those functions in place?
> >>
> >>     CC /tmp/build-perf/util/trace-event-read.o
> >> cc1: warnings being treated as errors
> >> util/trace-event-parse.c:2652:13: error: 'print_graph_cpu' defined but
> >> not used
> >> util/trace-event-parse.c:2681:13: error: 'print_graph_proc' defined but
> >> not used
> >> make: *** [/tmp/build-perf/util/trace-event-parse.o] Error 1
> >> make: *** Waiting for unfinished jobs....
> > 
> > All right, that's because you removed their calls in pretty_print_func_ent().
> > So either you remove the whole in a specific patch, pretty_print_func_ent()
> > included and other related functions, or you keep them.
> > 
> > But I prefer we don't do something halfway, and in particular not in a
> > semi-hidden way inside a patch that is not particularly focused on that
> > purpose.
> 
> You lost me on the halfway part.
> 
> So you want a separate patch that removes the code for an incomplete
> feature -- which means changing the references to the functions in that
> patch?

Yep.

> The intent being a patch that can be reverted later?

That can be reverted or something on top of which we can refer to
get that feature later.

In any case it is deadcode right now. If you remove it it should be
better done seperately. For all the reasons we always prefer to have
patches that do only one logic thing: easier to review, understand,
bisect, revert, find a bug, explain it, etc...

Ok, in fact you can actually keep it like you did: remove the cpu and
proc displays and let the rest of the function graph features. But
at least do it in an isolated patch because that should not be
an unnoticeable change, and for other reasons to make it a standalone
patch quoted above.

  reply	other threads:[~2011-03-10  0:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09 18:31 [GIT PULL 00/10] perf/core fixes and improvements Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 01/10] perf session: Simplify evlist creation from perf.data header Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 02/10] perf evsel: Assume rest of perf_header_attr functions Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 03/10] perf header: Stop using 'self' Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 04/10] perf top: Fix events overflow in top command Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 05/10] perf top: Don't let events to eat up whole header line Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 06/10] perf script: Change process_event prototype Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 07/10] perf script: Move printing of 'common' data from print_event and rename Arnaldo Carvalho de Melo
2011-03-09 23:50   ` Frederic Weisbecker
2011-03-10  0:04     ` David Ahern
2011-03-10  0:10       ` Frederic Weisbecker
2011-03-10  0:11         ` David Ahern
2011-03-10  0:14           ` Frederic Weisbecker
2011-03-10  0:22           ` Frederic Weisbecker
2011-03-10  0:32             ` David Ahern
2011-03-10  0:50               ` Frederic Weisbecker [this message]
2011-03-09 18:31 ` [PATCH 08/10] perf script: Support custom field selection for output Arnaldo Carvalho de Melo
2011-03-09 18:31 ` [PATCH 09/10] perf script: Add support for dumping symbols Arnaldo Carvalho de Melo
2011-03-09 23:30   ` Frederic Weisbecker
2011-03-10  0:21     ` David Ahern
2011-03-09 18:31 ` [PATCH 10/10] perf script: Add support for H/W and S/W events 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=20110310005001.GF2533@nowhere \
    --to=fweisbec@gmail.com \
    --cc=acme@ghostprotocols.net \
    --cc=acme@redhat.com \
    --cc=daahern@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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