From: Ryan Mallon <ryan@bluewatersys.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Greg KH <greg@kroah.com>,
Charles Manning <manningc2@actrix.gen.nz>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
akpm@linux-foundation.org
Subject: Re: [PATCH 0/10] Add yaffs2 file system: Fifth patchset
Date: Fri, 18 Feb 2011 13:55:04 +1300 [thread overview]
Message-ID: <4D5DC368.2080003@bluewatersys.com> (raw)
In-Reply-To: <20110218004354.GB27668@opensource.wolfsonmicro.com>
On 02/18/2011 01:43 PM, Mark Brown wrote:
> On Thu, Feb 17, 2011 at 04:33:53PM -0800, Greg KH wrote:
>> On Fri, Feb 18, 2011 at 12:01:50AM +0000, Mark Brown wrote:
>
>>> For the proc stuff - for tracing stuff then tracepoints are likely to be
>>> a good option if it's useful to people.
>
>> Then use the in-kernel tracing functionality, don't roll your own. And
>> that is not in /proc, so it should be there for this filesystem either.
>
> That'd be the tracepoints I was mentioning, then...
Are you suggesting that the yaffs_trace function should be replaced with
tracepoints?
yaffs_trace is basically just a wrapper around printk, which I suggested
should be replaced with pr_debug so that it can be compiled out
completely. Other drivers and filesystems have similar custom debugging
functions.
I haven't used tracepoints, but it seems like they are better suited to
tracing specific events than as a general printk style debugging
replacement?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
next prev parent reply other threads:[~2011-02-18 0:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-09 3:25 [PATCH 0/10] Add yaffs2 file system: Fifth patchset Charles Manning
2011-02-09 3:25 ` [PATCH 01/10] Add yaffs2 file system: allocators, bitmap and block handling Charles Manning
2011-02-09 3:26 ` [PATCH 02/10] Add yaffs2 file system: attrib and xattrib handling Charles Manning
2011-02-09 22:33 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 03/10] Add yaffs2 file system: checkpoint streaming Charles Manning
2011-02-10 22:27 ` Jesper Juhl
2011-02-10 22:44 ` Ryan Mallon
2011-02-10 22:50 ` Charles Manning
2011-02-09 3:26 ` [PATCH 04/10] Add yaffs2 file system: flash interface and ecc handling Charles Manning
2011-02-09 3:26 ` [PATCH 05/10] Add yaffs2 file system: tags handling Charles Manning
2011-02-09 3:26 ` [PATCH 06/10] Add yaffs2 file system: tracing and verification handling Charles Manning
2011-02-11 23:01 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 07/10] Add yaffs2 file system: yaffs1 and yaffs2 mode handling Charles Manning
2011-02-09 3:26 ` [PATCH 08/10] Add yaffs2 file system: core guts code Charles Manning
2011-02-10 2:27 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 09/10] Add yaffs2 file system: Linux glue code Charles Manning
2011-02-10 22:07 ` Ryan Mallon
2011-02-10 22:47 ` Charles Manning
2011-02-17 22:24 ` Ryan Mallon
2011-02-09 3:26 ` [PATCH 10/10] Add yaffs2 file system: hok in to Linux tree Charles Manning
2011-02-09 4:52 ` [PATCH 0/10] Add yaffs2 file system: Fifth patchset Christoph Hellwig
2011-02-09 18:22 ` Charles Manning
2011-02-16 8:04 ` Christoph Hellwig
2011-02-16 22:12 ` Charles Manning
2011-02-17 1:48 ` Mark Brown
2011-02-17 2:31 ` Charles Manning
2011-02-17 2:52 ` Ryan Mallon
2011-02-17 3:49 ` Charles Manning
2011-02-17 23:41 ` Greg KH
2011-02-18 0:01 ` Mark Brown
2011-02-18 0:33 ` Greg KH
2011-02-18 0:43 ` Mark Brown
2011-02-18 0:55 ` Ryan Mallon [this message]
2011-02-18 0:58 ` Greg KH
2011-02-20 17:25 ` Charles Manning
2011-02-20 20:07 ` Greg KH
2011-02-20 20:52 ` Ryan Mallon
2011-02-20 22:29 ` Greg KH
2011-02-20 22:57 ` Ryan Mallon
2011-02-18 1:08 ` Mark Brown
2011-02-17 3:49 ` Mark Brown
2011-02-17 4:22 ` Charles Manning
2011-02-17 6:08 ` Mark Brown
2011-02-19 17:45 ` Pavel Machek
2011-08-17 12:12 ` Linus Walleij
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=4D5DC368.2080003@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manningc2@actrix.gen.nz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).