Re: console_lock too early in printk???

[Aki M L. <aml...@cc...>]

On Sat, 1 Jul 2000, James Simmons wrote:
> > 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 

You tell me about it. On a laptop I have, I always have to be extremely
cautious not to say for example cat bigger text files. If I do, then the
whole machine is pretty much jammed, until it is done. During that time
even keyboard input (ctrl-c or changing virtual terminals) does not work.

> accelcon where nearly all the drivers use the video cards accel engine to
> draw for the console. This should nearly eliminate the latency problems.

Is it currently possible to make a driver which leaves the accel engine
do its work on the background so you don't have to wait by polling the 
hardware until the operation is done? With issues like this, it is still
possible that bigger blits will cause relatively big latencies. Certainly
not in the tens-of-seconds variety but unacceptable for the causes people
keep arguing here about.

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

I haven't got a picture how multihead will be worked out? Will you have
some per-head structure? Then it is natural to move most of the current 
global variables and locks in this structure.

> 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

Not so soon, sorry. I don't have time until thursday earliest.

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

If only you didn't need to printk fatal oopses/panics/etc, the portion of
code which would have to live in kernel would be pretty minimal.


-- 
D.