From: Jason Baron <jbaron@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Linux NFS ML <linux-nfs@vger.kernel.org>,
Linux NFSv4 ML <nfsv4@linux-nfs.org>,
SystemTAP ML <systemtap@sources.redhat.com>
Subject: Re: [patch 0/5] activate & deactivate dprintks individually and severally
Date: Wed, 21 Jan 2009 10:28:58 -0500 [thread overview]
Message-ID: <20090121152858.GA23953@redhat.com> (raw)
In-Reply-To: <20090120012930.020621000@sgi.com>
On Tue, Jan 20, 2009 at 12:29:30PM +1100, Greg Banks wrote:
>
> As mentioned in the recent discussion on NFS trace points on the NFS &
> SystemTap mailing lists. This patch allows field support staff and
> kernel developers debug kernel problems, by enabling them to treat
> dprintks as precise trace points rather than syslog spamming tools.
>
> This is a forward ported (from 2.6.16), updated, and split version
> of a patch that has been used in SGI's internal development tree for
> the last few months. The very first version of this was used about
> eighteen months ago when debugging NFS/RDMA, which has an enormous
> number of dprintks and no other way to debug it.
>
> Jason Baron suggested I post it here for review and contrast with
> his dynamic dprintk feature.
>
yes, these two patch sets are very similar in the problem that they are
addressing. For me, one of the core differences, is that 'dprintk' has
per-debug statement control, while my solution, 'dynamic debug' has a
more per-module focused control. 'dprintk' thus checks a different
variable per-debug line to see if its enabled. On the other hand
'dynamic debug' can check 1 global variable (in the most common cases),
to see if its enabled or not. I think we can layer per-line check on top
of the 1 global variable check and have a more efficient solution that
still allows for fine-grained debugging.
'dprintk' also has a richer user interface, which allows for file, line,
module, and statement control.
Thus, I think Greg and I can work together and combine the best features
of both patches. We will re-post a combined solution.
thanks,
-Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Baron <jbaron@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: Linux NFS ML <linux-nfs@vger.kernel.org>,
Linux NFSv4 ML <nfsv4@linux-nfs.org>,
SystemTAP ML <systemtap@sources.redhat.com>,
gnb@sgi.com
Subject: Re: [patch 0/5] activate & deactivate dprintks individually and severally
Date: Wed, 21 Jan 2009 10:28:58 -0500 [thread overview]
Message-ID: <20090121152858.GA23953@redhat.com> (raw)
In-Reply-To: <20090120012930.020621000@sgi.com>
On Tue, Jan 20, 2009 at 12:29:30PM +1100, Greg Banks wrote:
>
> As mentioned in the recent discussion on NFS trace points on the NFS &
> SystemTap mailing lists. This patch allows field support staff and
> kernel developers debug kernel problems, by enabling them to treat
> dprintks as precise trace points rather than syslog spamming tools.
>
> This is a forward ported (from 2.6.16), updated, and split version
> of a patch that has been used in SGI's internal development tree for
> the last few months. The very first version of this was used about
> eighteen months ago when debugging NFS/RDMA, which has an enormous
> number of dprintks and no other way to debug it.
>
> Jason Baron suggested I post it here for review and contrast with
> his dynamic dprintk feature.
>
yes, these two patch sets are very similar in the problem that they are
addressing. For me, one of the core differences, is that 'dprintk' has
per-debug statement control, while my solution, 'dynamic debug' has a
more per-module focused control. 'dprintk' thus checks a different
variable per-debug line to see if its enabled. On the other hand
'dynamic debug' can check 1 global variable (in the most common cases),
to see if its enabled or not. I think we can layer per-line check on top
of the 1 global variable check and have a more efficient solution that
still allows for fine-grained debugging.
'dprintk' also has a richer user interface, which allows for file, line,
module, and statement control.
Thus, I think Greg and I can work together and combine the best features
of both patches. We will re-post a combined solution.
thanks,
-Jason
next prev parent reply other threads:[~2009-01-21 15:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 1:29 [patch 0/5] activate & deactivate dprintks individually and severally Greg Banks
2009-01-20 1:29 ` Greg Banks
2009-01-20 1:29 ` [patch 1/5] Move definitions of struct module_sect_attr back into module.h Greg Banks
2009-01-20 1:29 ` Greg Banks
2009-01-20 1:29 ` [patch 2/5] Add apply_modules() which applies a function to each module Greg Banks
2009-01-20 1:29 ` Greg Banks
2009-01-20 1:29 ` [patch 3/5] Make the dprintk() macro record information about the callsite Greg Banks
2009-01-20 1:29 ` Greg Banks
2009-01-20 1:29 ` [patch 4/5] Add the dprintk module to allow dprintks to be activated/deactivated singly Greg Banks
2009-01-20 1:29 ` Greg Banks
2009-01-20 1:29 ` [patch 5/5] Add a module to test the dprintk module Greg Banks
2009-01-20 1:29 ` Greg Banks
2009-01-21 15:28 ` Jason Baron [this message]
2009-01-21 15:28 ` [patch 0/5] activate & deactivate dprintks individually and severally Jason Baron
-- strict thread matches above, loose matches on Subject: below --
2009-01-19 6:40 Greg Banks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090121152858.GA23953@redhat.com \
--to=jbaron@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.