David VomLehn wrote: > Our kernel does crash, so we have to do this. I had submitted a patch a > while ago that tweaks emit_log_char, but this was bounced, reasonably, > because it would be interferring with the great majority of people who > are not interested in capturing log output. The suggestion was made that > we do this with a console driver. I've recently got a version working, as > a module, but I've only started testing of the version integrated into the > kernel tree. Still, post early, post often, so I've appended a version > of the patch here to see if this seems to be the right direction. > > Regardless whether my particular patch seems like the right way to do this, > we do need to solve this problem for the embedded world. It is one of the > few areas where we have needs not shared by the rest of the kernel community.
In general, I like this approach to solve this problem. I spend most of my time in the lab with prototype boards that use a serial console, so my terminal history has always been my crashdump repository. ;-) This approach it unobtrusive to the rest of the log buffer system. I never did like the patches that introduced other ways to hack into the log buffer. The printk/log buffer code path is already convoluted enough, and I didn't like the idea of adding additional hooks. this approach leverages an already existing hook. I don't have much comment on the code specifics, but I have one nit with the config help... > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig > index 735bbe2..882ee57 100644 > --- a/drivers/char/Kconfig > +++ b/drivers/char/Kconfig > @@ -684,6 +684,20 @@ config HVCS > which will also be compiled when this driver is built as a > module. > > +config CONSLOGGER > + tristate "Pseudo-console for capturing console output" > + depends on PRINTK > + default n > + help > + This contains a pseudo-console to record and divert kernel console > + output, which is probably of most used to embedded systems. When should be "most use" (no 'd') > + a system crashes, it can divert printk output for logging information > + about the failure in some persistent location. Then the output from > + any function that uses printk() to display information, such as > + dump_stack() can be stored in the failure log. It also stores > + console output in a circular buffer so that that last <n> messages > + can be added to the failure log. > + > config IBM_BSR > tristate "IBM POWER Barrier Synchronization Register support" > depends on PPC_PSERIES ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
