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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
