lkml.org 
[lkml]   [2000]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: a joint letter on low latency and Linux
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site