On 9/29/2016 8:36 PM, Kees Cook wrote: > On Thu, Sep 29, 2016 at 5:55 PM, Sean Hudson <sean_hud...@mentor.com> > wrote: >> This patch set is based on Linus' v4.8-rc8 tag. >> >> This debug feature allows the kernel to use an external buffer and >> control block for kernel log messages. The feature is controlled by >> an optional command line parameter. The existing buffer and control >> block can contain existing log messages from previous boot cycles >> and/or the bootloader. The command line parameter was chosen for >> flexibility, cross arch portability, and the ability to dynamically >> enable/disable this feature. The parameter specifies the address of >> a control block used to replace the default log buffer. Existing >> bootloader and kernel log messages are kept, in order, inside the >> new buffer. After a boot that preserves the buffer contents, a >> bootloader can display both kernel and bootloader log entries from >> multiple, previous boots. It also allows the kernel to display >> bootloader log entries along with its own messages. >> >> This feature is intended for debug purposes and has no effect >> unless the command line parameter is specified. Further, it >> validates the passed control block carefully and if any checks >> fail, it falls back to the default behaviour. As such, it can be >> left enabled by default. >> >> Memory Reservation >> >> This feature expects the bootloader to reserve/preserve the shared >> buffer memory. This reservation needs to prevent the kernel from >> overwriting the external log control block and log entries. In my >> testing, I've used the 'fdt' commands in uboot to dynamically >> inject reserved memory regions via the DT to the kernel. > > Interesting! I wonder if this can be adjusted to incorporate the > existing console logging feature in the pstore which does a similar > thing? Though pstore doesn't know about bootloader logs, really, > it's just storing kernel logs in a ring buffer. Maybe this can > provide a backend to pstore or something, especially since pstore > initialization happens "too late" for this to really be very > sensible. It just seems like it'd be nice to have a single persistent > console memory region... >
I don't know that much about pstore. From your description though, it sounds feasible to put the two together at some point. How arch specific is pstore? -- Sean
signature.asc
Description: OpenPGP digital signature