Message-ID: <20081107051214.GA30350@Krystal>
Date:	Fri, 7 Nov 2008 00:12:14 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, alan@...hat.com,
	jbaron@...hat.com
Subject: Re: [PATCH] ftrace: add an fsync tracer

Hi Frank,

* Frank Ch. Eigler (fche@...hat.com) wrote:
> Hi -
> 
> On Thu, Nov 06, 2008 at 05:25:29PM -0500, Mathieu Desnoyers wrote:
> > [...]
> > > Arjan asked for something to send formatted strings to tracing buffers
> > > that are consumed by user space.  Whether internally that is done by
> > > markers, or by tracepoints converted to markers, or by tracepoints
> > > with custom ftrace_printf-y code, is indistinguishable to the user.
> > > 
> > > Can you be specific in what way any of that is exposing an "API
> > > directly to userspace"?
> > 
> > The tracepoint declaration is linked to the kernel code that is meant to
> > be traced. Given this code will change over time, it will be more
> > difficult to perform those changes if it is in any way coupled with
> > format strings exported to userspace via traced.  [...]
> 
> The userspace interface to all the various tracing widgets consists of
> the textual formatted trace data stream.

Oh ? Really ? I thought a binary data stream wasn't out of the question ?
Actually, having both ascii and binary output seems like a good way to
do it.

> ** IF ** these streams are
> to represent a long-term interface, can you elaborate why you believe
> it would be harder to generate identical text in the future with
> markers rather than another technique with more internal layers?  Can
> you work out an example?  
> 

Hum.. I never said it would be harder to generate the trace data. I said
it would be harder for kernel developers to change kernel code because
they would have to change (and understand the usefulness down to the
analysis tools) all the subtile tracepoint fields exported to userspace
tools. I am not willing to push tracepoints in the kernel as a
supplementary maintainance burden for kernel developers. With the format
string identifying subfield, this burden will fall on the kernel
developers. If we put the field selection in a callback sitting in a
different module, well, it won't compile for as long as nobody think
it's important enough to be fixed according to new in-kernel APIs, but
it won't break the standard kernel build, and this is a _must_.

> (BTW, is "traced" a typo?)
> 

Yep, I should have written "via a tracer".

> And as to that ** IF **: is there actually consensus that the format
> of tracing data generated by e.g.  ftrace engines are supposed to be
> preserved into the future versions, just as if they were a user-space
> interface like /proc files?  (That's certainly not my impression.)
> 

We aim at having a standardized buffer format at some point, and expect
the consumer tools to be shipped with the kernel tree for most part.
We also plan to put a version number on the trace buffer. I am merely
relating the discussions that led to Steven Rostedt unified trace buffer
mechanism. (I do not say it actually does everything that was agreed on,
but we have to start somewhere)

If I can get my head out of the sand and start posting the
implementations I have, we'll have more concrete stuff to discuss about
:) Only two things left on my 30-ish things long todo list.. almost
there ;)

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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