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: <201102210625.08616.manningc2@actrix.gen.nz>
Date:	Mon, 21 Feb 2011 06:25:08 +1300
From:	Charles Manning <manningc2@...rix.gen.nz>
To:	Greg KH <greg@...ah.com>
Cc:	Ryan Mallon <ryan@...ewatersys.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	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 Friday 18 February 2011 13:58:52 Greg KH wrote:
> 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?

The procfs is not used for tracing as , it is just one of the two ways 
ofsetting a trace mask to  select what to trace (the other is to set a trace 
mask).

eg.  echo +gc > /proc/yaffs

turns on the garbage collector tracing.

I will remove the /proc interface and write a userspace script to do the 
equivalent.

Realtime selection of tracing is valuable. It allows you to set up a test case 
with tracing disabled then select what you want to trace to get detail as you 
run the test case

I still intend to keep the tracing printk-based tracing:

#define yaffs_trace(msk, fmt, ...) do { \
	if (yaffs_trace_mask & (msk)) \
		printk(KERN_DEBUG "yaffs: " fmt "\n", ##__VA_ARGS__); \
} while (0)


> 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.

I was not aware of pr_debug I shall investigate how it works.

-- CHarles


--
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/