Re: console_lock too early in printk???

[Aki M Laukkanen]

On Sat, 1 Jul 2000, Andrew Morton wrote:

> There's one thing which bugs me about the console code.

Just one?-) I thought about this and the console latency problems a bit.
Would the following sound reasonable in mid/long-term? 

1. Get rid of the tasklet and setup a worker thread, kconsoled, to do
the dirty work. This has plus side that we can sleep and check if we
need rescheduling.

2. Create a new console semaphore and serialize with consoledriver.write 
by that means instead of the console spinlock.

Having done that there's still printk which is the big problem. How about
if we change semantics, 

printk: serializes by means of semaphore so can sleep. If in interrupt
then queue the job for the worker thread to do asynchronously. I think
most places in interrupts could change to use asynchronous semantics.
__printk: same but doesn't grab the lock - used inside console code?

This will leave us with that one ugly case (oopses/panics etc.) which
simply have to get the job done but maybe console is in inconsistant
state. So what to do, I'm not sure? Safe way would be to check an
atomic variable (console_dirty) and abort if no can do. The other strategy
would be to hope the best and see what happens.

I must have missed something? Btw. has anyone thought of pushing most
of console/vt code to user-space?

-- 
D.