Dear Frédéric, In message <20200319175737.10166-1-frederic.da...@collabora.com> you wrote: > This serie of patches adds a new pstore command allowing to display or save > ramoops logs (oops, panic, console, ftrace and user) generated by a previous > kernel crash. > PStore parameters can be set in U-Boot configuration file, or at run-time > using "pstore set" command. For kernel using Device Tree, the parameters are > dynamically added to Device Tree. > Records size should be the same as the ones used by kernel, and should be a > power of 2.
I wonder if we are reinventing the wheel here again? There is this feature in U-Boot which is called "shared log buffer"; a couple of years ago this was fully functional at least on Power and ARM architectures, but it was rarely used and probably has not been tested for years. A;so, the necessary tiny patch to have it supported in Linux as well never made it upstream (don't remember why, likely lack of time/interest). The functionality we had then was the following: - A memory area war reserved in U-Boot (typically at the upper end of memory) as a buffer that was shared between U-Boot and Linux. The format was as used for the kernel log buffer. - Upon boot, U-Boot would not re-initialize an existing log buffer, but keep it's content. That means, you could read and display the log buffer of the linux kernel that was running before the reset. After kernel crashes, pretty often this contained information that the kernel could not even print to the serial console any more. - In U-Boot, you could append log entries to that buffer. For example, this was used to record the results of the Power On Self Test (POST) routines (another feature that only few people still remember). - When booting Linux, the kernel syslog mechanism was used to extract the information from the log buffer in the usual way. The interesting fact here was that the Linux kernel was able to extract and save the kernel panic messages etc. from the crash before, plus any messages logged by U-Boot. To me this sounds very much like what you are adding here (plus a few features more). Does it make sense to unify such code? Added Heiko to Cc:, as he is currently working on fixes to get shared logbuffer working again for another project. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm what passes for a Unix guru in my office. This is a frightening concept. - Lee Ann Goldstein, in <3k55ba$c...@butch.lmsc.lockheed.com>
