Android ram-console upstreaming

Registered by John Stultz on 2012-05-01

Integrate and create a coheasive story around ram-console, persistent-ram, ramoops, pstore and persistent-ftrace.

Currently there are a number of different "persistent logging" solutions:

* ramoops: Upstream code that triggers to captures oops messages and stores them in ram (recently reworked to use pstore for a backend)

* pstore: Upstream generic infrastructure to store persistent data across reboots. Mostly ACPI spec driven.

* ram-console: Android functionality that continually captures console messages (including oopses) and stores them in ram (recently reworked to use persistent ram)

* persistent-ram: Android functionality that provides backend to store data in ram that supports persistence across reboots. Handles ECC and other features.

* persistent-ftrace: Android function that allows ftrace logs to be stored in persistent-ram.

I suspect the overall vision should be something like

[ram-console | persistent-ftrace | ramoops] => pstore interface => [persistent-ram | ACPI backend]

So ramconsonsole, persistent-ftrace and ramoops are all different front ends to pstore, which uses can use persistent ram or ACPI persistent flash as a backend.

Some complications: continuous console logging (ram-console/ftrace) can cause a lot of IO if we're sending data to flash on the backend. This could have latency issues. A solution to this could be pstore does continuous logging to ram, then writes to flash on oops if ram isn't persistent.

Blueprint information

Status:
Started
Approver:
John Stultz
Priority:
Medium
Drafter:
None
Direction:
Approved
Assignee:
Anton Vorontsov
Definition:
Approved
Series goal:
Accepted for kernel-merge-window
Implementation:
Deployment
Milestone target:
milestone icon 13.05
Started by
John Stultz on 2012-07-06

Related branches

Sprints

Whiteboard

Meta:
Roadmap id: CARD-509
Headline: Upstream ram_console driver functionality
Acceptance: Kernel console messages can be saved into persistent RAM regions (either platform-specified RAM region, and/or an address given on the kernel command line), and restored on the subsequent boots (via /proc or a special filesystem, like pstore).

[jakub-pavelek 2013-03-12] Lets validate AOSP has picked this up. 13.03 or around.

[jstultz 2013-05-06] Still waiting for a non-experimental AOSP tree to be released for validation, but the Android devs are clearly making use of it.

(?)

Work Items

Work items for 12.05:
Merge ramoops and persistent_ram code, turn them into a generic RAM backend for pstore: DONE
Switch ramoops driver to persistent_ram usage: DONE
Add ECC support for ramoops driver (now pstore/ram): DONE
Add console log messages support for pstore subsystem: DONE
Support for ramoops console log messages handling: DONE
Discuss ramoops and persistent_ram merge w/ the community: DONE
Get pstore/ram patches accepted into -next: DONE
Discuss ram_console and pstore merge w/ the community: DONE
Research persistent_ftrace functionality from AOSP tree, and look at how to integrate w/ pstore, prepare and send out patches: DONE

Work items for 12.06:
Get pstore/console patches accepted into -next (community likes the patches, but due to merge window, acceptance into -next delayed): DONE
Implement configurable ECC buffer size support (requested by Android folks): DONE
Implement early probing for pstore/ram backend (requested by Android folks): DONE
Resend pstore/ftrace with versioned trace data: DONE
Discuss pstore/ftrace patches with the community: DONE
Get pstore/ftrace support accepted into -next: DONE

Work items for 13.02:
Initial review of the *experimental* 3.8 AOSP branch looks like Android devs have picked up Anton's extentions to the pstore functionality: DONE

Work items for 13.04:
[jstultz] Review & push pstore enhansements from AOSP usptream (Queued by Anton for 3.10): DONE
[jstultz] New pstore enhansements from AOSP were merged in 3.10-rc1: DONE

Work items for backlog:
[jstultz] Validate AOSP picks up the work when an official 3.5+ AOSP branch is available: TODO
[jstultz] Validate Android userland uses this interrface with new Android userland is available: TODO

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.