The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC patch 3/5] ftrace trace event add missing semicolumn
Date: Thu, 6 Jan 2011 13:08:27 -0500	[thread overview]
Message-ID: <20110106180827.GB30610@Krystal> (raw)
In-Reply-To: <20110105234021.GC1692@nowhere>

* Frederic Weisbecker (fweisbec@gmail.com) wrote:
> On Wed, Jan 05, 2011 at 02:56:12PM -0500, Mathieu Desnoyers wrote:
> > * Frederic Weisbecker (fweisbec@gmail.com) wrote:
> > [...]
> > > Looks good!
> > > 
> > > I might be missing corner things but it seems this would reduce the code
> > > footprint (one function less) and turn more rw into ro datas.
> > > 
> > > So it seems to be a very valuable reason to change the semicolon requirement
> > > all over the place.
> > > 
> > > If you come up with this feature along the massive semicolon requirement
> > > change, we will probably happily apply the whole.
> > > 
> > > But coming with only the semicolon change is more like an empty shell.
> > 
> > My proposal here is to incrementally improve the tracing code, starting by
> > cleaning up what is already there. I cannot do this if you keep asking me for
> > larger changes to both Ftrace and Perf before any of the prerequisite cleanups
> > can make their way in.
> > 
> > In this thread, I demonstrated that the TRACE_EVENT cleanup I proposed opens a
> > lot of code/data size reduction cleanups for Ftrace and Perf. But let's get the
> > cleanup in there first (it does not break the current way Ftrace and Perf are
> > working), and once all the code-base has moved to the semicolumn-less semantic,
> > then we can start improving Ftrace and Perf.
> 
> Don't be suprised of my reaction. The way the things were presented was:
> 
> 1) A patch with an meaningless changelog, absolutely no idea why that new
> semicolon is useful for.
> 
> 2) Me asking you why
> 
> 3) You explaining me it's actually part of a much bigger cleanup for
> a goal almost completely useless
> 
> 4) Me has a hard time considering the big cleanup useful as is. Expressing
> my worries.
> 
> 5) You detailing much more the semicolon symptoms, and finally dropping an
> evasive reason to do this cleanup, collapsed in the obsure notion of "arrays
> of event"..
> 
> 6) Me still puzzled by the big cleanup just for the sake of unnoticeable
> files.i pollution cleanup. But I try to give some chance by asking to
> expand the "arrays of event" idea.
> 
> 7) You explaining me something that looks like a meaningful, useful reason for
> the big cleanup, but as a possibility. You propose me that I reuse the Lttng code that
> you pick as an example, not suggesting you're planing to handle that part.
> 
> 8) Me: ok for the big cleanup then, if you plan to also handle the useful change
> you detailed, because otherwise it's meaningless.
> 
> See? That meaningful reason came so late in the discussion, and was proposed
> so much under the angle of the possibility rather than something you plan
> that I just thought you would just drop that empty shell and run away.
> 
> Hence my worries.
> 
> But if you plan to do the thing incrementally, this is also perfectly ok.
> 
> And you know what, may be you won't eventually have the time to complete
> with the useful part. And may be someone else will handle that part.
> Whatever, it's ok. We don't always finish everything.
> But at least fill your changelogs with the useful longterm goal so that we
> know we are going somewhere with this.

Fair enough. I clearly see that for you it is tremendousy important to
understand what is the advantage of merging one of my patches, so I'll try to
better outline my motivation in the future. I seem to have misunderstood you
initially, thinking that you wanted me to push a large monster-patchset
- or nothing, which made me reluctant to tell you more about my plans. But if we
agree on working on these things incrementally, then I think we'll automatically
start benefiting from each other's work.

> > As we say in French, "il ne faut pas mettre la charrue devant les boeufs"
> > (roughly: don't put the cart before the horse)
> 
> As we say in French, "oui mais il a fallu te tirer les vers du nez"
> (roughly: right, but still I had to worm it out of you)

Thanks for coping with my attitude here. I might indeed not have been as
straightforward as I should. I'll work on that. Knowing that you are open about
incremental improvements, and that it's not a "all or nothing" policy, makes me
much more inclined to describe my motivation.

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

  parent reply	other threads:[~2011-01-06 18:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-04 23:16 [RFC patch 0/5] Trace event fixes and cleanups Mathieu Desnoyers
2011-01-04 23:16 ` [RFC patch 1/5] trace event block fix unassigned field Mathieu Desnoyers
2011-01-05 15:09   ` Jeff Moyer
2011-01-05 19:34     ` Mathieu Desnoyers
2011-01-05 19:57       ` Jeff Moyer
2011-01-04 23:16 ` [RFC patch 2/5] trace event skb " Mathieu Desnoyers
2011-01-04 23:16 ` [RFC patch 3/5] ftrace trace event add missing semicolumn Mathieu Desnoyers
2011-01-05  0:00   ` Frederic Weisbecker
2011-01-05  0:18     ` Mathieu Desnoyers
2011-01-05  2:08       ` Frederic Weisbecker
2011-01-05  2:35         ` Mathieu Desnoyers
2011-01-05  2:58           ` Frederic Weisbecker
2011-01-05 13:52             ` Mathieu Desnoyers
2011-01-05 15:02               ` Frederic Weisbecker
2011-01-05 19:56                 ` Mathieu Desnoyers
2011-01-05 23:40                   ` Frederic Weisbecker
2011-01-05 23:57                     ` Steven Rostedt
2011-01-06 18:08                     ` Mathieu Desnoyers [this message]
2011-01-05  3:01         ` Valdis.Kletnieks
2011-01-05  3:10           ` Frederic Weisbecker
2011-01-05  6:37             ` Valdis.Kletnieks
2011-01-05 13:56               ` Mathieu Desnoyers
2011-01-04 23:16 ` [RFC patch 4/5] tracepoint trace event add missing comma Mathieu Desnoyers
2011-01-04 23:16 ` [RFC patch 5/5] trace event sched: remove TP_perf_assign Mathieu Desnoyers
2011-01-05  9:58   ` Peter Zijlstra
2011-01-05 13:28     ` Mathieu Desnoyers

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=20110106180827.GB30610@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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