Re: [PATCH] ftrace: add an fsync tracer

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Hi -
> 
> On Thu, Nov 06, 2008 at 04:53:11PM -0500, Mathieu Desnoyers wrote:
> > [...]
> > > Something like
> > > 
> > > DEFINE_TRACE_FMT(sched_switch,
> > > 	TPPROTO(struct rq *rq, struct task_struct *prev,
> > > 		 struct task_struct *next),
> > > 	TPARGS(rq, prev, next),
> > > 	TPFMT("%d to %d\n", prev->pid, next->pid));
> > > 
> > > Which would be similar to attaching a trace_mark() to the trace point
> > > and can in these cases save a lot of lines of code.
> > > 
> > > Both lttng and the ftrace event tracer can use these default text
> > > strings.
> > 
> > Argh. No, please. Doing this would end up exposing the inner kernel API
> > (the tracepoints) directly to userspace. [...]
> 
> 
> 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"?
> 
> - FChE

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.

This is where using the markers as an indirection layer plays its role.

I also have a patch with "redux" markers, where I separate the marker
"declaration" from the marker "call". By doing this, I remove the need
for cascading function calls, which is more efficient.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68