Re: [Ksummit-discuss] [TECH TOPIC] printk redesign

[Andrew Lunn <andrew@lunn.ch>]

> Here's a couple of requirements that I expect from printk:
> 
> 1) First and for most, is the critical output. Those of warnings, and
> above. Basically all critical messages that can be used to debug a
> system crash. This requires the ability to be executed from any
> context, including NMI.
> 
>  This group includes WARN() and BUG() output, and anything in an oops.
> 
> 2) Activity information. This too can be used to debug a system crash,
> and requires serializations. When a device comes on line. A spurious
> interrupt. A system state change (CPU going on or off line).
> 
> 3) Status information. Now, I'm sure people will argue about what goes
> in this or the above #2. Here, this would be all pr_info. Useful
> information that should be logged, but perhaps not something that is
> critical knowledge if a crash happens. In other words, something that
> isn't critical to get out immediately.
> 
> 4) All other kernel information that's not critical at all, and perhaps
> doesn't even need to be serialized. At least, not against the above.
> This could be cached, and outputted at a later time than when the
> printk() was called.

Developers machine probably have different requirements to production
machines. When debugging during code development, i want the debug
output to be in the correct order, independent of the level. If you
are going to cause reordering, you might want to add a sequence number
to each output, so it is possible to put it back into the correct
order. And it needs to be clear when output is out of order.

       Andrew