Re: [PATCH 8/9] pstore/blk: use the normal block device I/O path

2020-11-08 Thread
On Fri, Oct 16, 2020 at 11:33 PM Christoph Hellwig wrote: > > Stop poking into block layer internals and just open the block device > file an use kernel_read and kernel_write on it. Note that this means > the transformation from name_to_dev_t can't be used anymore, and proper > block device file

Re: simplify pstore-blk

2020-11-08 Thread
hi Christoph, On Fri, Oct 16, 2020 at 9:27 PM Christoph Hellwig wrote: > > Hi all, > > this series cleans up and massively simplifies the pstore-blk code, > please take a look. Thanks for your code. I am going to redesign pstore/blk referred to your idea. I want to split pstore/blk into two

Re: [PATCH 2/9] pstore/blk: update the command line example

2020-11-08 Thread
On Fri, Oct 16, 2020 at 9:28 PM Christoph Hellwig wrote: > > Use the human readable device name instead of the device number, and > add the required best_effort parameter. > > Signed-off-by: Christoph Hellwig > --- > Documentation/admin-guide/pstore-blk.rst | 2 +- > 1 file changed, 1

Re: [PATCH 1/9] pstore/zone: cap the maximum device size

2020-11-08 Thread
On Fri, Oct 16, 2020 at 9:27 PM Christoph Hellwig wrote: > > Introduce an abritrary 128MiB cap to avoid malloc failures when using > a larger block device. > > Signed-off-by: Christoph Hellwig > --- > fs/pstore/zone.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/fs/pstore/zone.c

Re: [RFC v5 3/4] pstore/blk: support pmsg for pstore block

2019-01-23 Thread
On 2019-01-18 08:17, Kees Cook wrote: > On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong > wrote: >> >> To enable pmsg, just set pmsg_size when block device register blkzone. > > At first pass, this looks like a reasonable extension of blkzone. Is > it possible to add console, ftrace, etc, too? > I

Re: [RFC v5 2/4] pstore/blk: add sample for pstore_blk

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

Re: [RFC v5 0/4] pstore/block: new support logger for block devices

2019-01-07 Thread
On 2019-01-08 05:47, Kees Cook wrote: > On Mon, Jan 7, 2019 at 4:01 AM liaoweixiong > wrote: >> >> Why should we need pstore_block? >> 1. Most embedded intelligent equipment have no persistent ram, which >> increases costs. We perfer to cheaper solutions, like block devices. >> In fast, there is

Re: [RFC v4 0/3] pstore/rom: new support logger for block devices

2019-01-03 Thread
hi Tony: On 2019-01-04 01:18, Luck, Tony wrote: > I'm curious why you call this "pstore/rom" rather than the more descriptive > "pstore/block". Because there is "pstore/ram", so i name it as "pstore/rom". It's nice to rename it "pstore/block", i will change it in next version of patch. > > It

Re: [PATCH] pstore: fix crypto dependencies of 842/zstd compression

2018-12-18 Thread
hi , On 2018/12/17 16:16, kbuild test robot wrote: > Hi liaoweixiong, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on kees/for-next/pstore] > [also build test ERROR on v4.20-rc7 next-20181214] > [if your patch is applied to the wrong git tree, please drop us

Re: [PATCH] pstore: fix crypto dependencies of 842/zstd compression

2018-12-13 Thread
在 2018年12月13日 02:43, Kees Cook 写道: On Wed, Dec 12, 2018 at 12:24 AM liaoweixiong wrote: Reference to commit 58eb5b670747 ("pstore: fix crypto dependencies"), which fixed crypto dependencies of deflate, lzo, lz4 and lz4hc compression, but omitted 842 and newer compression zstd from commit

Re: [PATCH] pstore: fix crypto dependencies of 842/zstd compression

2018-12-12 Thread
In fast, there is no any failure while building or configuring on the newest codes. The patch of commit 58eb5b670747 ("pstore: fix crypto dependencies") makes the pstore itself select the crypto core if PSTORE_COMPRESS is set. This fixes the dependence bug at all in my tests. But this patch