Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path

Frank Ch. Eigler
2009-01-19T15:41:41Z

Hi -

On Mon, Jan 19, 2009 at 10:12:55AM +1100, Greg Banks wrote:
> [...]
> > It would make more sense to me to turn dprintk's into trace_marks,
> Umm, ok. Sorry to be so ignorant but where would I find the doc that
> tells me about adding trace marks ?

Documentation/markers.txt

> The control interface seems a little primitive. It seems like you
> can only activate and deactivate single printks ?

Or single classes (identical names) per activate/deactivate call.

> I don't see a way to e.g. activate every trace make in a particular
> function, or in a particular .c file. I thought both of these were
> useful things to do, so I implemented them. Below is an extract
> from the doc that accompanies the sgi-dprintk module. [...]

Very clever!

I am not an insider enough to carry much weight in this regard, but it
would make most sense to me if the sgi-dprintk widget were adapted so
that:
- it used trace_mark() as the low-level hook mechanism at the call sites
- it extended the trace_mark structures to track
__FILE__/__LINE__/__FUNCTION__ values
- it extended the marker activation API to be able to specify queries
based upon those __FILE__/etc. fields
- as an extension to the proposed marker->ftrace patch, extend the
option parser the same way as your /proc/dprintk does

The benefits might not be huge, but:
- it would reuse existing functionality (markers for the hooks, other
ftrace widgets for extra info to gather at each event - like the
stack traces)
- it could generalize the handling of these dprintks, by not just
being tied to message printing, but becoming of possible use for
statistics/health monitoring

- FChE