[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D5DC368.2080003@bluewatersys.com>
Date: Fri, 18 Feb 2011 13:55:04 +1300
From: Ryan Mallon <ryan@...ewatersys.com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC: Greg KH <greg@...ah.com>,
Charles Manning <manningc2@...rix.gen.nz>,
Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
akpm@...ux-foundation.org
Subject: Re: [PATCH 0/10] Add yaffs2 file system: Fifth patchset
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@...ewatersys.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists