Messages in this thread | | | Subject | Re: a joint letter on low latency and Linux | Date | Fri, 7 Jul 2000 16:39:38 -0400 (EDT) | From | (Michael Borrelli) |
| |
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/
| |