Thread (2 messages) 2 messages, 1 author, 2003-05-28

Re: Console & FBDev vs. locking

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2003-05-28 12:49:46
Also in: lkml

On Wed, 2003-05-28 at 13:46, Benjamin Herrenschmidt wrote:
All printk originated console call should done with the console
semaphore held. The console-sem is the de-facto locking mecanism for the
console today, while not fine-grained, it's probably plenty enough for
what we need in 2.5 and unless previous implementations which ran with
irqs off, the console drivers can actually block and rely on HW
interrupts.
Hrm... Of course, this is only true for things like resize/mode change,
etc... (and soon blanking once I'm done with it). The way the console
sem is used is so that normal output originating from printk can
still happen at interrupt time.

BTW. I know some people would prefer not doing so, but I'd like to
eventually disable that 'feature', or at least add a flag to the the
consw driver telling if it supports beeing called at interrupt/spinlock
time or not, and if not, defer operations to process context. ..

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help