On Thu, Dec 30, 2010 at 5:10 PM, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> wrote: >> > pr_err? Or is this based on a module parameter? >> >> The macro PRINT_ERROR() has been defined in the header file >> include/scst/scst_debug.h. For this macro and also for related macros >> (e.g. TRACE_DBG()) the user can configure via debugfs whether or not >> PID, function name and/or line number should be included in the >> generated messages. > > Hmm, at one hand that is neat, but at other I am wondering if it would be > better to use CONFIG_DYNAMIC_PRINTK functionality (which is what pr_debug > could be used for) - which is a more generic framework for this. (resending as plain text) Hello Konrad, As far as I can see CONFIG_DYNAMIC_PRINTK was introduced in kernel 2.6.28 but has been renamed to CONFIG_DYNAMIC_DEBUG in 2.6.30 ? The dynamic debug framework comes close but does not provide all the functionality we need. While the macros in <scst/scst_debug.h> assign a class to each generated line of debug output, the macros in <linux/dynamic_debug.h> treat all generated debug lines equal. Yet while debugging it is very convenient to be able to enable only one class of debug statements and let all others disabled. The SCST macros and debugfs files allow to enable only a specific class of debug statements. A quote from dynamic-debug-howto.txt: <quote> Dynamic debug is designed to allow you to dynamically enable/disable kernel code to obtain additional kernel information. Currently, if CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_debug() calls can be dynamically enabled per-callsite. Dynamic debug has even more useful features: * Simple query language allows turning on and off debugging statements by matching any combination of: - source filename - function name - line number (including ranges of line numbers) - module name - format string * Provides a debugfs control file: <debugfs>/dynamic_debug/ control which can be read to display the complete list of known debug statements, to help guide you </quote> > Some of these errors look relevant to the user so perhaps going through the > debugfs is not proper? Or is it that there are just so many of them that it > is unclear which ones would be relevant? Messages generated by one of the PRINT_*() macros also go to the kernel log when the kernel has been built with CONFIG_SCST_DEBUG=n while messages generated via one of the TRACE_*() macros only go to the kernel log if the kernel has been built with CONFIG_SCST_DEBUG=y and the corresponding class has been enabled via debugfs. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
