Hello!
> Note that printk() during normal kernel operations _is_ a bug.
>
> printk() should happen only for (a) initialization and (b) exceptional
> events. I fyou get printk's while doing streaming audio, you have other
> trouble, and whatever causes that trouble should be fixed.
Agreed. But if we want to allow printk's in those emergency situations, we
still must lock the console subsystem somehow to avoid collisions between
normal console output and the printk's. The most ugly point is that some
gfx cards (Matrox, to name one) lock up when trying to touch the frame buffer
while the accelerator accesses it. And these locks definitely should not
keep interrupts disabled as they do now. Being a sssslllooowww action,
scrolling of the FB should be interruptible and perhaps even preemptive.
When thinking about it, once I ended up with this solution: use two locks:
one non-IRQ-safe (maybe a semaphore) protecting the whole console machinery
from re-entering and one IRQ-safe protecting just the console data structures.
When printk'ing, try to grab the big lock. If it succeds, do everything normally,
if it doesn't, call a special function of the low-level console driver which
waits for the accels to finish, make sure the cursor is on a sane position
and then do the printing.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> <mj@suse.cz> http://atrey.karlin.mff.cuni.cz/~mj/ "A mathematician is a machine for converting coffee into theorems."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:22 EST