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

Ingo Molnar
2009-03-25T10:51:19Z

* 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