Re: [Dle-develop] [RFC][PATCH] kmsg_dumper for NVRAM

[Seiji A. <sei...@hd...>]

Hi Tony,

>I wonder whether you could use my pstore file system interface
>for this ... you'd need to write a backend that used EFI variable
>space to save the pieces of a console log, in much the same way
>that I used ERST to stash the pieces.
>
>This might be a bit messy - but I think that it would be
>worth doing in order to provide a single user interface
>to the kmsg_dump on different architectures, regardless
>of the underlying storage method used.

I will check whether I could use your pstore file system interface.
Could you please send your latest patch to me?

Seiji

>-----Original Message-----
>From: Luck, Tony [mailto:ton...@in...]
>Sent: Tuesday, February 01, 2011 2:47 PM
>To: Américo Wang; Seiji Aguchi
>Cc: rd...@xe...; Yu, Fenghua; tg...@li...; mi...@re...; hp...@zy...; x8...@ke...;
>tj...@ke...; ak...@li...; a.p...@ch...; ar...@ar...; lin...@vg...;
>lin...@vg...; lin...@vg...; dle...@li...; sh...@re...;
>pj...@re...; Satoru Moriya
>Subject: RE: [RFC][PATCH] kmsg_dumper for NVRAM
>
>> This looks like what Tony wanted, pstore.
>
>Yes - this looks like another means to the same end (making console log
>Available after a crash).
>
>I wonder whether you could use my pstore file system interface
>for this ... you'd need to write a backend that used EFI variable
>space to save the pieces of a console log, in much the same way
>that I used ERST to stash the pieces.
>
>This might be a bit messy - but I think that it would be
>worth doing in order to provide a single user interface
>to the kmsg_dump on different architectures, regardless
>of the underlying storage method used.  I.e. the OS
>vendors would just have to write startup scripts to glean
>information from /dev/pstore and clear it by removing the
>files there. Rather than having one set of scripts that
>looks at EFI variables for machines that use that, a different
>set for machines that have the sparc64 method of saving in
>some special area of ram, and yet another set for a machine
>that has some other motherboard magical non volatile storage
>that hasn't been designed yet.
>
>-Tony