lkml.org 
[lkml]   [2008]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ftrace: add an fsync tracer
Hi -

On Thu, Nov 06, 2008 at 01:13:48PM -0800, Arjan van de Ven wrote:
> [...]
> fche@redhat.com (Frank Ch. Eigler) wrote:
>
> > Arjan van de Ven <arjan@infradead.org> writes:
> >
> > > [...]
> > > what is the real need is
> > > 1) Have a trace point in the source
> > > 2) Associate a "formatting function" with that point
> > > (which basically transforms the trace parameters to, say, a
> > > string) 3) A way to turn the trace point on/off.
> >
> > For 1 and 2, it may be worth considering a plain trace_mark() in
> > do_sync(). The complication that makes this uglier than a one-liner
>
> no why is that?
>
> what you really need is to be able to provide a callback function
> pointer that will do the formatting, or as Peter wants it, a format string.
> [...]
> Doing this like you propose is just too complex and too specialistic;
> the reality is that merely formatting the arguments of a trace point is
> the common case, and I suspect for 99.9% of the cases we can get away
> with a standard default formatting.

I don't understand what you're arguing against. If formatting strings
learn to deal with struct files, then the marker approach would be
even simpler, and the fsync "tracer" would consist of this single line:

trace_mark (fsync, "process %s fsyncd file %pF\n", comm->execname, file);

Via some simple additional generic code (the generic marker->ftrace
backend), that would turn into exactly the "merely formatting the
arguments ... 99.9% of the cases" you're talking about.


- FChE


\
 
 \ /
  Last update: 2008-11-06 22:23    [W:0.069 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site