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·¥Š{±ý…æ* jg¬±¨ ¶‰šŽŠÝjÿ¾«þG«é¸ ¢·¦j:+v‰¨Šwèm¶Ÿÿþø®w¥þŠà£¢·hšâÿ†Ù
