On 2019-01-18 08:21, Kees Cook wrote: > On Thu, Jan 17, 2019 at 4:15 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> >> On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong >> <liaoweixiong@xxxxxxxxxxxxxxxxx> wrote: >>> >>> 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 >
