[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1158350716.5724.488.camel@localhost.localdomain>
Date: Fri, 15 Sep 2006 22:05:16 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Roman Zippel <zippel@...ux-m68k.org>
Cc: Ingo Molnar <mingo@...e.hu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
"Frank Ch. Eigler" <fche@...hat.com>, karim@...rsys.com,
Tim Bird <tim.bird@...sony.com>,
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>,
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 Fri, 2006-09-15 at 21:10 +0200, Roman Zippel wrote:
> >
> > this is being worked on actively: there's the "djprobes" patchset, which
> > includes a simplified disassembler to analyze common target code and can
> > thus insert much faster, call-a-trampoline-function based tracepoints
> > that are just as fast as (or faster than) compile-time, static
> > tracepoints.
>
> Who is going to implement this for every arch?
> Is this now the official party line that only archs, which implement all
> of this, can make use of efficient tracing?
In the reverse you are enforcing an ugly - but available for all archs -
solution due to the fact that there is nobody interested enough to
implement it ?
If there is no interest to do that, then this arch can probably live w/o
instrumentation for the next decade too.
tglx
-
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