Date:	Mon, 23 Feb 2009 23:16:59 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	"Frank Ch. Eigler" <fche@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org, zippel@...ux-m68k.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] tracing/markers: make markers select tracepoints

On Mon, 2009-02-23 at 13:32 -0500, Theodore Tso wrote:
> On Mon, Feb 23, 2009 at 12:31:31PM -0500, Steven Rostedt wrote:
> > > The impression that this is somehow different with tracepoints is
> > > mistaken.  Tracepoints are *exactly* as "ABI-like" as markers.
> > 
> > I disagree with this point. markers are text strings that will eventually 
> > appear to userspace. trace points need translation. A trace point can be 
> > modified at any time and should never mess up user apps.
> > 
> > You may have a hook to a trace point that provides user apps a text based 
> > output. If the trace point changes, this hook may break. But the tracer 
> > maintainer of that hook will be responsible for that change, not the 
> > maintainer of the code the tracepoint existed in.
> 
> So stupid question time --- exactly who is supposed to write and
> maintain trnaslation code; the "hook"?  What trace points have done is
> added an extra layer of indirection, but in order for someone to
> actually make *use* of the have the trace point, someone has to
> maintain the "hook".

That just means we have to make it easier to write/generate this glue,
no? If we had function argument debug data (see below) we could generate
a generic tracepoint hook.

> I'm sorry I've offended Peter with the ext4 trace_mark() hooks, but
> it's what I could forsee needing if someone wants reports a wierd sh*t
> bug in ext4 and I wanted to be able to be able to extract debugging
> information without forcing them to patch and recompile the kernel,
> and in the ideal world, without even needing to reboot the kernel.
> (If we had usable and reliable debuginfo information, in most cases
> I'd be able simply use access to function parameters as replacements
> for trace_mark().)

We're working on adding arguments to the function/graph tracer, it would
fit all your above requirements and doesn't need any source modification
to boot.

Furthermore, most of it is upstream.

> I've had to debug problems in the field on customer machines where
> installing a new kernel was a big deal (as in, you get a window to
> reboot the machine every 24 hours, and the problem is so complex you
> can't replicate it anywhere *but* the production environment).  It's
> also been the case that more than once I've seen wierd behaviour on my
> laptop, and being able to peer inside it to see what is going on
> easily and conveniently is a major win.

Yeah, I know, the function graph tracer is brilliant that way. It even
provides information on the rest of the system and requires no
additional patches or big lumps of userspace.

> Finally, whether or not the text string is an ABI really depends on
> the tools.  Given that the string is self describing, it's only an ABI
> if the tools are stupid.  

>  This really isn't rocket science....

It isn't, yet how many scripts/programs have you seen that failed at the
above?


--
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