On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:
On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman <m...@ellerman.id.au> wrote:
Michal Suchánek <msucha...@suse.de> writes:
On Mon, 17 Apr 2017 20:43:02 +0530
Hari Bathini <hbath...@linux.vnet.ibm.com> wrote:
On Friday 14 April 2017 01:28 AM, Michal Suchánek wrote:
more (optional) properties cannot be added?
Kernel change seems simple over f/w enhancement..
That certainly looks so when you are a kernel developer and can
implement the change yourself compared to convincing some firmware
developer that this feature makes sense.
On the other hand, the proposed kernel-only solution introduces
requirement that the maintainer does not like.
For the platform as a whole does it make more sense to add a hack to
the kernel or does it make sense to enhance the firmware to provide
more options for firmware-assisted dump?
Unfortunately it doesn't really matter, because there is firmware out
there that implements the current behaviour and will never be updated.
So we have to work with what's there.
It's not that with the existing firmware fadump does not work. It just
uses more memory than needed. So if new firmware revision allows more
flexibility it will work for people with updated firmware and people
with outdated firmware will get the current behavior.
The memory saving is only significant for big systems so only people
running those will get significant improvement from the updated
firmware.
Hi Michal,
With the fadump_append= approach I posted in this response thread,
additional parameters are enforced when fadump is active. If f/w supports
appending additional parameters, it has to update chosen/bootargs
whenever fadump is active. Almost the same thing except the dirty job
is now done by f/w? Hence I thought fadump_append= kernel parameter
approach is simple and lesser of the two evils? Am i missing something
here..
Thanks
Hari
