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
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
