Martin Mares said this...
>
>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.
I'm not sure why printk() needs to have a complicated algorithm. Under
normal circumstances (that were pointed out above) (a) happens on boot and
there shouldn't be much problem with locks, and (b) only happens when
there's a problem so even if it is slow in this case, it's only reporting
that something went wrong (or some debugging messages that would be
removed before the code is 'published'.)
I admit that I'm very much a newbie here, but it seems that the effort to
make a faster printk() would be better off in other areas, since, in the
best of all worlds, it wouldn't ever be used during normal operation
anyway?
-mjb
-
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