On Sat, 6 Sep 2008 13:39:55 +0200
"Frédéric Weisbecker" <fweisbec@gmail.com> wrote:

> 2008/9/4 Steven Rostedt <rostedt@goodmis.org>:
> 
> > For logdev (my pet project from way back, and the latest ftrace is based
> > on), I had a CUSTOM type. The API allowed to register a callback to a
> > type, and it would associate that type to some number (descriptor) and
> > pass that number back to you. Then you could use this number to write to
> > the buffer using the CUSTOM type and registered number. On output, when a
> > CUSTOM type is detected, it would read the custom.id (the number) and
> > search for any registered callbacks to handle the entry.
> >
> > This probably would not be too difficult to implement. Especially since it
> > is already implemented in logdev.
> > (see http://rostedt.homelinux.com/logdev/)
> >
> > -- Steve
> 
> Why not. It is a way for a tracer to handle output for any type of entries.
> But will this feature really be used for other special types than
> TRACE_PRINT? I'm not sure... If it is not the case, the Pekka's
> solution seems to me far more simple.
> 
> But actually I don't know the needs of others tracers...

I never thought TRACE_PRINT would need anything more. At least I'm happy
with the concept of TRACE_PRINT, it just needs some adjustments in the API
to be nice to use.

True, I might some day want to add yet another entry type for mmiotrace,
but I'm not planning that for now, and I could just add it like they are
in the current framework. But the benefit of the CUSTOM type would be
to allow modularized and out-of-tree tracers. And then, why keep the
current predefined types, why not make everything a CUSTOM type? Just
define a block size in the ring buffer and use TRACE_CONT to handle
payload larger than the block.

Anyway, personally I'm satisfied with the current state of the framework
and I can only talk for mmiotrace.


Cheers,
pq

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/