[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060919120517.GB4965@infradead.org>
Date: Tue, 19 Sep 2006 13:05:17 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Karim Yaghmour <karim@...rsys.com>
Cc: Ingo Molnar <mingo@...e.hu>, Tim Bird <tim.bird@...sony.com>,
Roman Zippel <zippel@...ux-m68k.org>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108
On Thu, Sep 14, 2006 at 04:46:21PM -0400, Karim Yaghmour wrote:
> Ideally, though, markers should be self-contained. IOW, the person
> implementing such a marker should not need to edit any other file
> that the one being worked on to add an instrumentation point --
> at least that's the way I think is easiest. What this means is that
> you would be able to add an instrumentation point in the kernel,
> build it, run the tracing and view the trace with your new event
> without any further intervention on any tool, header, or anything
> else.
Just in case my first mail on this subject wasn't clear enough I
completely agree with that statement. complex traces detaches from
the actual sourcecode are an uteer maintaince nightmare and should
be avoided for anything but spontanous debugging. For that case they
are of course imensely useful. Thus we need two forms to specify
probes, and to not make the tracing an utter mess they need to share
as much infrastructure as possible.
-
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/
Powered by blists - more mailing lists