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:tony.luck@xxxxxxxxx]
>Sent: Tuesday, February 01, 2011 2:47 PM
>To: AmÃrico Wang; Seiji Aguchi
>Cc: rdunlap@xxxxxxxxxxxx; Yu, Fenghua; tglx@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; hpa@xxxxxxxxx; x86@xxxxxxxxxx;
>tj@xxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; a.p.zijlstra@xxxxxxxxx; arnd@xxxxxxxx; linux-doc@xxxxxxxxxxxxxxx;
>linux-kernel@xxxxxxxxxxxxxxx; linux-ia64@xxxxxxxxxxxxxxx; dle-develop@xxxxxxxxxxxxxxxxxxxxx; shiyer@xxxxxxxxxx;
>pjones@xxxxxxxxxx; 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
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þ&ºã¶›¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf
|