All of lore.kernel.org
 help / color / mirror / Atom feed
From: "'Jason Baron'" <jbaron@redhat.com>
To: Takashi Nishiie <t-nishiie@np.css.fujitsu.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	joe@perches.com, greg@kroah.com, nick@nick-andrew.net,
	randy.dunlap@oracle.com, mathieu.desnoyers@polymtl.ca
Subject: Re: [PATCH 0/8] dynamic debug
Date: Mon, 16 Jun 2008 14:19:21 -0400	[thread overview]
Message-ID: <20080616181920.GA30284@redhat.com> (raw)
In-Reply-To: <009201c8cf58$58909080$09b1b180$@css.fujitsu.com>

On Mon, Jun 16, 2008 at 11:26:12AM +0900, Takashi Nishiie wrote:
> Jason Baron wrote:
> >Each kernel sub-system seems to have its own way of dealing with 
> >debugging statements. Some of these methods include 'dprintk', 
> >'pr_debug', 'dev_debug', 'DEBUGP'. There are also a myriad of 
> >ways of enabling these statements. 
> 
>  I propose to replace 'Pr_debug', 'Dev_debug', and 'DEBUGP' with 
> kernel markers. SystemTap is used for the output of the log.  
> 
>  I propose to make it to the function to output only specified 
> kernel markers as a log and the function in a word like LTTng of
> a simple version by using the framework and kernel markers of 
> ftrace if the log is output by using debugfs. 
> 
> Thank you,
> 

perhaps markers could be used to replace 'pr_debug', 'dev_debug', and 'DEBUGP'
but i have yet to see patches for that...

In a number of ways, these dynamic debug patches differ from markers:

-Markers have a pre-defined format string and arguments list, whereas debug
statements have a 'printk' format
-these patches are built around per-module debugging, which is largely implicit
whereas markers explicitly define sets of related markers.
-these patches allow 'flags' and levels to be set per-module, markers do not 
have this concept.
-these patches are tied into a procfs control file, whereas markers are
controlled by kernel modules which register handlers.

These two patchsets are really addressing different problems afaict.

thanks,

-Jason




  reply	other threads:[~2008-06-16 18:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 18:57 [PATCH 0/8] dynamic debug Jason Baron
2008-06-16  2:26 ` Takashi Nishiie
2008-06-16 18:19   ` 'Jason Baron' [this message]
2008-06-18 16:02   ` Greg KH
2008-06-18 19:27   ` Pavel Machek
2008-07-01  5:08 ` Andrew Morton

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=20080616181920.GA30284@redhat.com \
    --to=jbaron@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=nick@nick-andrew.net \
    --cc=randy.dunlap@oracle.com \
    --cc=t-nishiie@np.css.fujitsu.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.