resend this email.

On 2019-01-18 08:21, Kees Cook wrote:

On Thu, Jan 17, 2019 at 4:15 PM Kees Cook [off-list ref] wrote:

quoted

On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong
[off-list ref] wrote:

quoted

It is a sample for pstore_blk, using general ram rather than block device.
According to pstore_blk, the data will be saved to ram buffer if not
register device path and apis for panic. So, it can only used to dump
Oops and some things will not reboot.

I'm not sure I see the purpose of this implementation? Doesn't this
just cause all the pstore machinery to skip any actions? i.e. without
bzinfo->part_path, won't blkz_sample_write() just return -EINVAL, etc?

Say, instead of a no-op driver, can you build something like the how
ramoops processes module parameters, so that a person can define an
arbitrary device at boot time for blkoops? This also allows for easier
runtime testing too.

Sure, i will do it in next version. But it can only use for oops,
excluding panic.
I have no idea how to pass panic operation parameters.

This all looks good, with some minor tweaks as mentioned. And on
closer review, yeah, it doesn't look like it shares much with ramoops.
:)

Thanks for sending this series; I look forward to the next version. :)

-Kees