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

["Frank Ch. Eigler" <fche@redhat.com>]

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