printk documentation
PATCH 1/1 printk documentation
Hi Philippe
Running some full kernel package builds with 2.6.23 & Xenomai v2.4.x, and once again hit a problem I reported in May[1] - This issue as crept back in causing the kernel documentation targets to fail.
Patch attached to resolve the problem.
Regards, Paul.
[1] https://mail.gna.org/public/adeos-main/2007-05/msg00034.html
--- kernel/printk.c | 40 ++++++++++++++++++++-------------------- 1 files changed, 20 insertions(+), 20 deletions(-)
kernel/printk.c +23 -23
@@ -479,29 +479,6 @@ static int have_callable_console(void)return 0 ; } -/** -* printk - print a kernel message -* @fmt: format string -* -* This is printk(). It can be called from any context. We want it to work. -* Be aware of the fact that if oops_in_progress is not set, we might try to -* wake klogd up which could deadlock on runqueue lock if printk() is called -* from scheduler code. -* -* We try to grab the console_sem. If we succeed, it's easy - we log the output and -* call the console drivers. If we fail to get the semaphore we place the output -* into the log buffer and return. The current holder of the console_sem will -* notice the new output in release_console_sem() and will send it to the -* consoles before releasing the semaphore. -* -* One effect of this deferred printing is that code which calls printk() and -* then changes console_loglevel may break. This is because console_loglevel -* is inspected when the actual printing occurs. -* -* See also: -* printf(3) -*/ -#ifdef CONFIG_IPIPE static ipipe_spinlock_t __ipipe_printk_lock =IPIPE_SPIN_LOCK_UNLOCKED ;
@@ -534,6 +514,29 @@ void __ipipe_flush_printk (unsigned virq, void *cookie)spin_unlock_irqrestore (&__ipipe_printk_lock, flags); } +/** +* printk - print a kernel message +* @fmt: format string +* +* This is printk(). It can be called from any context. We want it to work. +* Be aware of the fact that if oops_in_progress is not set, we might try to +* wake klogd up which could deadlock on runqueue lock if printk() is called +* from scheduler code. +* +* We try to grab the console_sem. If we succeed, it's easy - we log the output and +* call the console drivers. If we fail to get the semaphore we place the output +* into the log buffer and return. The current holder of the console_sem will +* notice the new output in release_console_sem() and will send it to the +* consoles before releasing the semaphore. +* +* One effect of this deferred printing is that code which calls printk() and +* then changes console_loglevel may break. This is because console_loglevel +* is inspected when the actual printing occurs. +* +* See also: +* printf(3) +*/ + asmlinkage int printk(const char *fmt, ...) {int r, fbytes, oldcount, cs =-1 ;
Signature · 1 line
1.4.4.4
Quoted 6 lines · Paul
Hi Philippe
Running some full kernel package builds with 2.6.23 & Xenomai v2.4.x, and once again hit a problem I reported in May[1] - This issue as crept back in causing the kernel documentation targets to fail.
It seems that I only merged it to the 2.6.20-noarch branch at that time, and for some reason, this patch slipped away from the latest versions.
Quoted 3 lines
Patch attached to resolve the problem.
Now merged in all active -noarch branches from my tree (2.6.20, 2.6.23 and 2.6.24), thanks.
Signature · 1 line
Philippe.