On 02/21/2011 11:29 AM, Greg KH wrote: > On Mon, Feb 21, 2011 at 09:52:00AM +1300, Ryan Mallon wrote: >> On 02/21/2011 09:07 AM, Greg KH wrote: >>> On Mon, Feb 21, 2011 at 06:25:08AM +1300, Charles Manning wrote: >>>> On Friday 18 February 2011 13:58:52 Greg KH wrote: >>>> 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) >>> >>> No, please don't invent your own stuff like this, again, use the >>> in-kernel functionality provided for this. >> >> Do you mean using pr_debug? Other filesystems (see for example >> fs/ubifs/debug.h:dbg_do_msg) and drivers have similar approaches to this >> to allow printk debugging with multiple message levels. > > Yes, other ones do have this, and it's a pain, and not consistant across > the kernel, and usually just not worth it at all. > > Please use the standardized functions for this, you do not need to roll > your own at all. What standardised functions are there for managing debug printk's with different log types? For example, yaffs currently allows printk debugging to be enabled individually for garbage collection, check pointing, bad blocks, etc. I am at least in favour of switching to pr_debug and using pr_fmt for the "yaffs: " prefix, but what should the yaffs_trace_mask be replaced with? My understanding is that replacing the proc interface which controls the yaffs_trace_mask with a more sane sysfs one (ie exposing yaffs_trace_mask directly), and keeping the yaffs_trace macro but replacing the printk with pr_debug so that it can be compiled out completely should be sufficient. i.e.: #ifdef CONFIG_YAFFS_DEBUG #define DEBUG #endif #define pr_fmt "yaffs: " fmt #define yaffs_trace(msk, fmt, ...) do { \ if (yaffs_trace_mask & (msk)) \ pr_debug(fmt, ##__VA_ARGS__); \ } while (0) > > Especially for trace stuff. I think we are conflating two things here. Tracepoints have been suggested as a replacement for some parts of the printk debugging, such as the mtd debugging. However, it is likely that much of the printk debugging remains useful and is not ideally replaced by tracepoints. ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon 5 Amuri Park, 404 Barbadoes St ryan@xxxxxxxxxxxxxxxx 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html