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

[David VomLehn <dvomlehn@cisco.com>]

Grant Likely wrote:
> On Tue, Aug 12, 2008 at 06:30:54PM -0700, David VomLehn wrote:
>>
>> Regardless of implementation, it seems to me that it could be of use for 
>> some other embedded platforms. Any suggestions as to where it should go 
>> in the tree? drivers/char? drivers/misc?
> 
> Depends on what you're storing to.  Can you send more details about the
> specific use case that you will use this interface for?

The system I'm working on is a settop box. It is in an environment where it is 
connected to a central server. The settop box doesn't have enough space to hold 
core dumps and the upstream connection to the server has too little bandwidth to 
upload them if we did store them. We have found that we can usually diagnose and 
fix problems with much less information than a core dump however, so we want to 
be able to capture that information and send it upstream.

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.

> g.
--
David VomLehn