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

[Tim Bird <tim.bird@am.sony.com>]

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 proposing storing the data in a specific place; that will be up
> to the platform. We will be storing in a piece of memory set aside for
> this purpose, but storing it in NOR flash makes a lot of sense, too, or
> using NAND flash or possibly even disk. All I'm proposing is a small
> framework that will allow plugging in a logging function when needed and
> removing it when done. I'll do the common piece that looks like a fake
> console and we, and other people, can use the simpler interface it
> provides.

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?

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?  That is,
change your steps to:

1. Register a panic handler
2. The kernel panics and calls our panic handler
3. Record the current position of the log buffer insertion point
4. Print registers, stack, memory, and various other pieces of
    information using standard kernel functions, which all use printk
5. As printk output is generated - it is stored by the kernel
 in the log buffer (no change to printk code is needed).
** (not sure what the trigger is to stop, here) **
6. Record the current position of the log buffer, and transfer
data logged between steps 3 and 6 to wherever you like.  That
is, copy it directly from the log buffer.
7. The panic handler exits
8. The kernel does the rest of its usual panic handling

This reduces your intrusion to just your trigger points, and
grabbing the log buffer position.  (Side Note - the way the log
buffer position is stored is a bit funky.  It is an absolute
value that monotonically increases, and is masked when used
to refer to the buffer.  This is why the log buffer size
is constrained to a power of two).
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================