Re: [PATCH] [RFC] emit-crash-char: Allow diversion of printk output for crash logging

[David VomLehn <dvomlehn@cisco.com>]

Tim Bird wrote:
> David VomLehn wrote:
>> Our use case is:
>> 1. We register a panic handler
>> 2. The kernel panics and calls our panic handler
>> 3. We register a function to log printk output
>> 4. We print registers, stack, memory, and various other pieces of
>>    information using standard kernel functions, which all use printk
>> 5. As printk output is generated, we store it in memory
>> 6. We unregister the printk logging function
>> 7. The panic handler exits
>> 8. The kernel does the rest of its usual panic handling
...
> 
> I'm not sure exactly what triggers the transition from step 5 to 6 in
> your steps above.  That is, how do you know when to unregister the
> printk logging function?

The printk logging function is unregistered when we are done printing everything 
we're interested in.

> But, taking a step back, instead of storing the information somewhere
> else, why not just use the log buffer as the storage medium, and transfer
> that all-at-once when you've collected the information you want?  

An interesting suggestion, but we've seen cases where the logging itself causes 
subsequent faults. In such cases, you would get nothing at all if you waited to 
store information until you've collected everything. A partial report, 
particularly if you've tried to print the most useful things first, is better 
than none at all. In addition, there is the risk that, for a particularly long 
report, you might wrap the log buffer and lose the first part of your output.
--
David VomLehn