[ltt-dev] [PATCH] tracepoints: Generate Module.tracepoints file

[Mathieu Desnoyers]

* Frank Ch. Eigler (fche at redhat.com) wrote:
> Hi -
> 
> On Mon, Sep 22, 2008 at 10:53:32PM -0400, Mathieu Desnoyers wrote:
> > * Frank Ch. Eigler (fche at redhat.com) wrote:
> > > Jan Blunck <jblunck at suse.de> writes:
> > > 
> > > > This adds support to generate the Module.tracepoints file by modpost. This
> > > > can be read by tools like SystemTap very similar to the Module.markers file.
> > > > [...]
> > > 
> > > For systemtap, the problem with tracepoints is not so much knowing the
> > > list of them, but knowing how to dynamically interface to them.  In
> > > particular, the parameter type signatures are a problem because they
> > > can be general C type decls, which are hard just to parse.
> > 
> > Why would you want to deal with tracepoints dynamically ? [...]
> 
> Because I disprefer tracepoint-to-marker conversion modules.  Even if
> you imagine hand-coded tracepoint consumer code sitting inside
> systemtap, then the "Module.tracepoints" file is not needed anyway.
> 

Agreed. There is no need for a Module.tracepoints file. I think I
pointed this out earlier in this thread.

> > And remember, tracepoints are meant to be few, well thought and not to
> > cange too often once things settle down.
> > OTOH, markers can be used as temporary debugging statements, which makes
> > it understandable to follow their changes dynamically.
> 
> I hope this peculiar dichotomy can be redressed as a part of the
> current lkml "unified tracing buffer" discussion.
> 

Can you tell a little bit more about your expectations ?

Mathieu

> - FChE
> 

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