>> It looks to be a really good idea.
> Should i add "Acked-by" in next version of patch?
I've only looked at the concept, not at the code yet. So too early to commit to
an "Acked-by"
> I have little experience in sending patch to upstream linux.
You are doing fine so far.
-Tony
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
I'm curious why you call this "pstore/rom" rather than the more descriptive
"pstore/block".
It looks to be a really good idea.
I think you need to document how the "write" function for the block device must
be written.
Since pstore calls this at "panic" time, the write path:
+ Cannot allocate
Why should we need pstore_rom?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have
4 matches
Mail list logo
