This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path
- From: Jason Baron <jbaron at redhat dot com>
- To: Jeff Moyer <jmoyer at redhat dot com>
- Cc: Greg Banks <gnb at melbourne dot sgi dot com>, Steve Dickson <SteveD at redhat dot com>, Linux NFSv4 mailing list <nfsv4 at linux-nfs dot org>, Linux NFS Mailing list <linux-nfs at vger dot kernel dot org>, SystemTAP <systemtap at sources dot redhat dot com>
- Date: Mon, 19 Jan 2009 14:49:58 -0500
- Subject: Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path
- References: <49711BDF.3010605@melbourne.sgi.com> <x49ab9ntlpp.fsf@segfault.boston.devel.redhat.com>
On Mon, Jan 19, 2009 at 09:27:30AM -0500, Jeff Moyer wrote:
> Greg Banks <gnb@melbourne.sgi.com> writes:
>
> > Steve Dickson wrote:
> >> So the ultimate goal would be to replace all the dprintks with trace points
> >> but still be able to enable them through the rpcdebug command
> > I have a patch which changes the definition of the dprintk() macro (but
> > *not* dprintk() callsites) to allow enabling and disabling individual
> > dprintk() statements through a /proc/ interface. Would you be
> > interested in that?
>
> That sounds like duplicated work. How does it differ from Jason Baron's
> dynamic printk patches (which I believe are now upstream)?
>
> Cheers,
> Jeff
indeed. I've implemented a solution in a very similar problem space
which is now upstream, see:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=346e15beb5343c2eb8216d820f2ed8f150822b08;hp=33376c1c043c05077b4ac79c33804266f6c45e49
One of the core fundamental differences that I see is that 'dprintk'
checks a global variable per dprintk line. Whereas, 'dynamic printk'
assigns each module a set of bits in a *single* global variable. The
idea was that if you have thousands of these debug lines throughout the
kernel, I wanted to have a small footprint.
The per-dprintk granularity could be implemented on top of the
per-module approach that i've taken. That is, each dprintk statement
could activate the module that its associated with when its activated.
Then, a further per-line variable could be checked.
We should probably move this discussion to lkml, since this probably
should involve a wider audience. Perhaps, you can re-post your patchset
there?
thanks,
-Jason