linux-kernel - Re: [PATCH 0/10] Add yaffs2 file system: Fifth patchset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110218005852.GA14546@kroah.com>
Date:	Thu, 17 Feb 2011 16:58:52 -0800
From:	Greg KH <greg@...ah.com>
To:	Ryan Mallon <ryan@...ewatersys.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.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 Fri, Feb 18, 2011 at 01:55:04PM +1300, Ryan Mallon wrote:
> 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?

If you want printk(), then yes, use pr_debug() as it ties into the
dynamic debug infrastructure, which is great.

Then you can remove the proc files, as the kernel already controls the
debug interface through the standard way, no need for a custom one.

thanks,

greg k-h
--
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/