On Thu, May 17, 2012 at 1:37 AM, Anton Vorontsov <anton.vorontsov@xxxxxxxxxx> 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@xxxxxxxxx Other than my comment on logging console into a single record, Acked-by: Colin Cross <ccross@xxxxxxxxxxx> 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. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
