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
--
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
