[Ce-android-mainline] ram console

Tim Bird tim.bird at am.sony.com
Fri Jan 20 18:46:10 UTC 2012

On 01/20/2012 10:08 AM, Shuah Khan wrote:
> Thanks for the feedback and good discussion. It helps me understand the
> use cases for this feature in the field. Based on what I heard so far
> (Thanks Tim, Todd, and Colin for your input), my proposal to use
> ram-oops and pstore will not be a complete solution to cover all the cases.
> Hence, with the new information, here is the going forward plan proposal,
> - Socialize the idea to include ram console in the mainline on lkml
> � (after testing ram console on 3.3 and 3.2.1 stable.) with the goal to
> move ram console from staging area into the mainline driver area.
> - Once ram console gets into main driver area, refactoring persistent
> storage out of the ramconsole driver could be pursued, as the current
> use cases for this feature are of development nature if I understood
> what Colin said correctly.
> Hope this plan sounds like the right next step.

That sounds like a good plan.  If there's pushback on mainlining
this as is, it will be good to get the feedback from LKML on what
the issues are.  If it's just "this looks too much like pstore
or ramoops", then we at least have some differences to back up
an argument for taking it as is.

My guess is that the addition of a new /proc thing (last_kmsg)
might rub people the wrong way.  But I don't want to put ideas
into people's minds, so I wouldn't mention that up front. :-)

Overall, my take on this is that it is a very tidy and elegant
solution to the problem of persisting the kernel messages from
one kernel boot to the next.  If this had gotten in a long time
ago, it would have saved me years of doing this:

With any luck it will save me from having to do that in the future.

Thanks for working on this!
 -- Tim

Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment

More information about the Ce-android-mainline mailing list