Jonathan de Boyne Pollard wrote:

> Welcome to *exactly* the problems that face printk() in Linux. Linux
> uses roughly the approach that you outlined. (The buffer is flushed
> when the task holding the console lock comes to unlock it.)

You generally want to rate-limit printk's anyway. Being able to produce
more than 129Kb of output in a fraction of a second is no more useful
than being able to produce 128Kb. So you can use a fixed-sized buffer
that's drained by a service thread. If the buffer fills, drop messages
on the floor. If the service thread dies, 128Kb later, you stop
logging.

Odds are you'll capture the most useful information. If you don't die,
you'll get the beginnings of whatever storm hit you, which is most
likely what you need to fix it. If you do die, you'll capture how you
died rather than your unlimited death throes.

DS

davids@webmaster.com wrote:
> Jonathan de Boyne Pollard wrote:
....
> You generally want to rate-limit printk's anyway. Being able to
> produce more than 129Kb of output in a fraction of a second is no
> more useful than being able to produce 128Kb. So you can use a
> fixed-sized buffer that's drained by a service thread. If the buffer
> fills, drop messages on the floor. If the service thread dies, 128Kb
> later, you stop logging.

If not in there already, add numbers to the messages to see where the lost
were supposed to be and have a global counter for the lost messages.

Alex