On (19/11/13 02:25), Dmitry Safonov wrote: > I guess I've pointed that in my point of view price for one-time testing > code is cheaper than adding a new printk feature to swap log levels on > the fly. [..] > I've gone through functions used by sysrq driver and the same changes > introducing log level parameter would be needed for: sched_show_task(), > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of > them don't need any platform changes, but at least show_regs() needs. Good points and nice conclusion. Well, here we go. There is a number of generally useful functions that print nice data and where people might want to have better loglevel control (for debugging purposes). show_stack() is just one of them. Patching all those functions, which you have mentioned above, is hardly a fun task to do. Hence the printk() per-CPU per-context loglevel proposition. The code there is not clever or complicated and is meant for debugging purposes only, but with just 3 lines of code one can do some stuff: /* @BTW you can't do this with "%s" KERN_FOO ;P */ + printk_emergency_enter(LOGLEVEL_SCHED); + debug_show_all_locks(); + printk_emergency_exit(); Now... I'm not sure if this whole thing is up to "printk maintainers only". If no one is going to use "emergency printk contexts" then there is no point in having that code in the kernel. -ss _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
