On Mon, May 07, 2012 at 10:40:00AM -0700, John Stultz wrote:
On 05/07/2012 10:33 AM, Anton Vorontsov wrote:
- ram_console feature seemed quite interesting, so I started looking more closely into it. Based on previous lkml discussions, it appears that the main obstacle is that we should use pstore. So, as a warm-up I started porting ramoops (which uses pstore in -next tree) driver to use persistent_ram. That would be a good reason to move persistent_ram out of staging/.
From the discussions on the list, it it seemed we might want to use persistent_ram as a back end for pstore, instead of having ramoops use it directly. This allows drivers to target one interface (pstore) and have it multiplex the data back to the proper storage for the device.
I guess there's some misconception, probably because ramoops have recently switched to pstore (like 4 days ago ;-).
Pstore consists of three things: 1. An interface to store and retrieve messages (a backend iface); 2. A filesystem driver to represent retrieved messages; 3. Plus there is an ad-hoc oops dumper right inside the pstore.
Today ramoops is a ram storage facility for DMESG message type of pstore (badly named, as it stores only kernel dumps, not the whole dmesg as ram_console).
Ramoops is using pstore to receive messages, then it stores the messages (into RAM) and retrives them back [from RAM to pstore]. So ramoops is already a RAM backend for pstore, it just doesn't support ECC.
The plan is this:
1. make ramoops use persistent_ram library, basically this just adds an (optional) ECC support for ramoops. 2. add a new message type for pstore (KMSG, DMESG_ALL?) that denotes the whole kernel log; 3. make ram_console pass messages to the pstore instead of persistent_ram (with "DMESG_ALL" message type), then we can rename ram_console to pstore_kmsg or merge it into fs/pstore/platform.c, near the kmsg_dumper code; 4. rename ramoops.c to pstore_ram.c and persistent_ram.c to pstore_ram_core.c (or merge the two), as from now on it is just a RAM backend for pstore w/ ECC support.