Re: console_lock too early in printk???

[James S. <jsi...@ac...>]

> 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.

That's a interesting idea. The problem is mostly with fbcon. It just takes
to long to draw pixel by pixel. In time I hope to see fbcon move to become 
accelcon where nearly all the drivers use the video cards accel engine to
draw for the console. This should nearly eliminate the latency problems.
Their will still be offb and vesafb which have no accel support but has
more accelerated fbdev drivers come into being this will go away.   
 
> 2. Create a new console semaphore and serialize with consoledriver.write 
> by that means instead of the console spinlock.

This needs to be done. Soon or later we are going to run into video
hardware that is irq driven only. Also once the kernel supports multihead 
we most likely will run into problems. So the locking system needs to be 
thought out. By next week I will have multihead running for mdacon and
vgacon so I will find out. 

> 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?

Do you think you can come up with some code to try out. As I said by next
week I will have multihead running so we can give these ideas a try. As
for moving the console/vt code to userspace. In theory you can do this
using /dev/fbX and /dev/eventX to create a userland console.