linux-kernel - Re: [PATCH 3/8] Add yaffs2 file system: guts code

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] [day] [month] [year] [list]

Date:	Tue, 07 Dec 2010 17:49:54 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Charles Manning <manningc2@...rix.gen.nz>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH 3/8] Add yaffs2 file system: guts code

On Wed, 2010-12-08 at 09:43 +1300, Charles Manning wrote:

> > Adding the TRACE_EVENT() code is also simple too ;)
> 
> For 500 traces?

Are all of them for the BUFFER code?

> 
> Please remember that yaffs is typically used in embedded systems - not big 
> iron servers . Typical kernel sizes are between 1 and 3MB. Pretty much all 
> the big iron features get turned off.

OK then what about just using printk(KERN_DEBUG, ...)


> Yaffs is used in embedded systems (eg. phones). There is no operator. The only 
> people that ever look at dmesg and the log are engineers during 
> integration/testing.

OK, then use pr_debug(), these can even be compiled out of the kernel
for production.


> 
> > There's also levels of printks that you 
> > can do:
> >
> > KERN_ERR, KERN_WARING, KERN_INFO, KERN_DEBUG, etc.
> >
> > But again, these go to the users console and into the message logs.
> > If 
> > it is something that is a high activity this can slow down the system as
> > printk's are synchronous. That is, they don't continue work until they
> > finished writing. If you have a serial console, that could really slow
> > things down.
> 
> That is exactly why I use the bitmasks to be able to be able to select sets of 
> messages to be enabled. [btw: Enabling sets of traces seems to be a feature 
> that TRACE_EVENT() lacks, or perhaps I have not read enough].

You can group trace_events into TRACE_SYSTEMS, and then enable a bunch
of events under which system they are in. I thought about making this
into a hierarchy, but have yet seen the true need for that.


> 
> The trace mask allows you to set up a test case very easily and delivers the 
> output where it is readily available.
> 
> >
> > printk's should not be used for real debugging anyway. But putting it
> > into a tracepoint, then it opens up lots of options.
> >
> > Your T(YAFFS_TRACE_ALWAYS, ...) look like good candidates for printks.
> >
> > TRACE_EVENTS() are those that just want to analyze what is happening in
> > the system.
> 
> All, well almost all, embedded systems have printk. Many don't have TRACE.
> 
> People using yaffs do not want to lose what they already have and like the way 
> tracing is set up.
> 
> What I propose is just rewriting the current trace mechanism so the code looks 
> cleaner.

Fine, as it seems special purpose for embedded devices.

-- Steve


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