[PATCH v2 0/6] Merge ram_console into pstore

Colin Cross ccross at android.com
Thu May 17 18:42:29 UTC 2012


On Thu, May 17, 2012 at 1:37 AM, Anton Vorontsov
<anton.vorontsov at linaro.org> wrote:
> Hi all,
>
> In v2:
>
> - Updated documentation per Colin Cross' comments;
> - Corrected return value in ramoops_pstore_write() (noticed by Kees Cook);
> - Fixed large writes handling in pstore_console_write(), i.e. when
>  log_buf write is larger than pstore bufsize. Also Noticed by Kees Cook.
>
> These patches depend on the the following series:
> http://thread.gmane.org/gmane.linux.kernel/1298642
> "[PATCH v3 0/3] Merge ramoops and persistent_ram, generic pstore RAM backend"
>
> And a rationale for the series:
>
> Currently pstore doesn't support logging kernel messages in run-time,
> it only dumps dmesg when kernel oopses/panics. This makes pstore
> useless for debugging hangs caused by HW issues or improper use of HW
> (e.g. weird device inserted -> driver tried to write reserved bits ->
> SoC hanged. In that case we don't get any messages in the pstore.
>
> This series add a new message type for pstore, i.e. PSTORE_TYPE_CONSOLE,
> plus make pstore/ram.c handle the new messages.
>
> The old ram_console driver is removed. This might probably cause
> some pain for out-of-tree code, as it would need to be adjusted...
> but "no pain, no gain"? :-) Though, if there's some serious resistance,
> we can probably postpone the last two patches.
>
> Thanks!
>
> --
> Anton Vorontsov
> Email: cbouatmailru at gmail.com

Other than my comment on logging console into a single record,
Acked-by: Colin Cross <ccross at android.com>

There is one feature that ram_console had but lost when I added
persistent_ram, which would be nice to get back:  registering the
platform driver before module_init, to allow it to log oopses that
happen during device probing.  This requires changing module_init to
postcore_initcall, and switching from platform_driver_probe to
platform_driver_register because the platform device is not registered
when the platform driver is registered.  Depending on what functions
are __init, it may cause a cascading change from __init to __devinit
as well.



More information about the devel mailing list