Re: [PATCH 58/61] dynamic debug: combine dprintk and dynamic printk

[Ingo Molnar <mingo@elte.hu>]

* Greg Kroah-Hartman <gregkh@suse.de> wrote:

> From: Jason Baron <jbaron@redhat.com>
> 
> This patch combines Greg Bank's dprintk() work with the existing 
> dynamic printk patchset, we are now calling it 'dynamic debug'.
> 
> The new feature of this patchset is a richer /debugfs control file 
> interface, (an example output from my system is at the bottom), 
> which allows fined grained control over the the debug output. The 
> output can be controlled by function, file, module, format string, 
> and line number.

Hm, dunno this overlaps quite a bit with existing tracing 
facilities.

There seems to be serious consolidation potential here, if you want 
to reduce code and want to cooperate with existing tracing 
facilities.

In particlar, this facility seems to be a subset of what is already 
possible via trace_printk(). We could make every dprintk() site show 
up in /debug/tracing/events/dprintk/, and make it possible to toggle 
them on/off individually.

Furthermore it would also be possible to use the user-defined per 
tracepoint filter expression facility. That way each dprintk site 
can be (optionally) tailored individually.

For example we could enable such use:

  echo 'pid == 1234' > /debug/tracing/events/dprintk/fs/lockd/svc4proc.c:71/filter
  echo 1             > /debug/tracing/events/dprintk/fs/lockd/svc4proc.c:71/enabled

To tailor the following dprintk() in fs/lockd/svc4proc.c (line 71):

  static __be32
  nlm4svc_proc_null(struct svc_rqst *rqstp, void *argp, void *resp)
  {
          dprintk("lockd: NULL          called\n");
          return rpc_success;
  }

To only be printed for PID 1234.

Per subsystem filters would be available too. The subsystem 
maintainers dont have to do anything but place dprintk() calls - 
they'll show up under /debug/tracing/events/dprintk/ automatically.

Would you be interested in this?

	Ingo