From: Hari Bathini <hbathini@linux.vnet.ibm.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH v5 2/2] powerpc/fadump: update documentation about 'fadump_append=' parameter
Date: Thu, 11 May 2017 02:00:11 +0530 [thread overview]
Message-ID: <e1485f4d-f346-fea6-ee2a-9c7a6b2f6587@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170510180132.1fa0c1ec@kitsune.suse.cz>
Hello Michal,
On Wednesday 10 May 2017 09:31 PM, Michal Suchánek wrote:
> Hello,
>
> On Wed, 03 May 2017 23:52:52 +0530
> Hari Bathini <hbathini@linux.vnet.ibm.com> wrote:
>
>> With the introduction of 'fadump_append=' parameter to pass additional
>> parameters to fadump (capture) kernel, update documentation about it.
>>
>> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
>> ---
>>
>> Changes from v4:
>> * Based on top of patchset that includes
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=akpm&id=05f383cdfba8793240e73f9a9fbff4e25d66003f
>>
>>
>> Documentation/powerpc/firmware-assisted-dump.txt | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/powerpc/firmware-assisted-dump.txt
>> b/Documentation/powerpc/firmware-assisted-dump.txt index
>> 8394bc8..6327193 100644 ---
>> a/Documentation/powerpc/firmware-assisted-dump.txt +++
>> b/Documentation/powerpc/firmware-assisted-dump.txt @@ -162,7 +162,15
>> @@ How to enable firmware-assisted dump (fadump):
>> 1. Set config option CONFIG_FA_DUMP=y and build kernel.
>> 2. Boot into linux kernel with 'fadump=on' kernel cmdline option.
>> -3. Optionally, user can also set 'crashkernel=' kernel cmdline
>> +3. A user can pass additional command line parameters as a comma
>> + separated list through 'fadump_append=' parameter, to be enforced
>> + when fadump is active. For example, if parameters like nr_cpus=1,
>> + numa=off & udev.children-max=2 are to be enforced when fadump is
>> + active, 'fadump_append=nr_cpus=1,numa=off,udev.children-max=2'
>> + can be passed in command line, which will be replaced with
>> + "nr_cpus=1 numa=off udev.children-max=2" when fadump is active.
>> + This helps in reducing memory consumption during dump capture.
>> +4. Optionally, user can also set 'crashkernel=' kernel cmdline
>> to specify size of the memory to reserve for boot memory dump
>> preservation.
>>
>>
> Writing your own deficient parser for comma separated arguments when
> perfectly fine parser for space separated quoted arguments exists in
> the kernel and the bootloader does not seem like a good idea to me.
Couple of things that prompted me for v5 are:
1. Using parse_early_options() limits the kind of parameters
that can be passed to fadump capture kernel. Passing parameters
like systemd.unit= & udev.childern.max= has no effect with v4.
Updating
boot_command_line parameter, when fadump is active, seems a better
alternative.
2. Passing space-separated quoted arguments is not working
as intended with lilo. Updating bootloader with the below
entry in /etc/lilo.conf file results in a missing append
entry in /etc/yaboot.conf file.
append = "quiet sysrq=1 insmod=sym53c8xx insmod=ipr
crashkernel=512M-:256M fadump_append=\"nr_cpus=1 numa=off
udev.children-max=2\""
Because lilo doesn't seem to handle quoted arguments as intended,
comma-separated list syntax was the obvious choice. Quoted arguments
for a comma-separated list sounds plausible though, provided the
bootloader can handle it. Will try and address that..
> I also do not see how this addresses
>
> On Wed, 26 Apr 2017 20:32:55 +1000
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> Hari Bathini <hbathini@linux.vnet.ibm.com> writes:
>>
>>> diff --git a/arch/powerpc/kernel/fadump.c
>>> b/arch/powerpc/kernel/fadump.c index 8ff0dd4..87edc7b 100644
>>> --- a/arch/powerpc/kernel/fadump.c
>>> +++ b/arch/powerpc/kernel/fadump.c
>>> @@ -338,6 +343,36 @@ unsigned long __init
>>> arch_reserved_kernel_pages(void) return memblock_reserved_size() /
>>> PAGE_SIZE; }
>>>
>>> +static void __init parse_fadump_append_params(const char *p)
>>> +{
>>> + static char fadump_cmdline[COMMAND_LINE_SIZE] __initdata;
>>> + char *token;
>>> +
>>> + strlcpy(fadump_cmdline, p, COMMAND_LINE_SIZE);
>>> + token = strchr(fadump_cmdline, ',');
>>> + while (token) {
>>> + *token = ' ';
>>> + token = strchr(token, ',');
>>> + }
>>> +
>>> + pr_info("enforcing additional parameters (%s) passed
>>> through "
>>> + "'fadump_append=' parameter\n", fadump_cmdline);
>>> + parse_early_options(fadump_cmdline);
>> Using parse_early_options() means it only works for parameters defined
>> with early_param() or __setup() doesn't it?
>>
>> That might be OK but at least you need to clearly document it.
> which was your gripe with v4 of the patchset. Unfortunately the flags
> in Documentation/kernel-parameters.txt do not include a flag that
> denotes parameters available with parse_early_options - unless it is
> the KNL flag and is quite bitrotten.
>
>
The addtional comments Michael was asking for was when fadump_append=
is limited to early parsing only. But with this approach, we don't
have such limitation. Though I do agree that there is always scope
to improve the documentation further..
Thanks
Hari
next prev parent reply other threads:[~2017-05-10 20:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 18:22 [PATCH v5 1/2] powerpc/fadump: reduce memory consumption for capture kernel Hari Bathini
2017-05-03 18:22 ` [PATCH v5 2/2] powerpc/fadump: update documentation about 'fadump_append=' parameter Hari Bathini
2017-05-10 16:01 ` Michal Suchánek
2017-05-10 20:30 ` Hari Bathini [this message]
2017-05-11 13:16 ` Michal Suchánek
2017-05-12 9:45 ` Hari Bathini
2017-05-12 15:42 ` Michal Suchánek
2017-05-15 7:29 ` Hari Bathini
2017-05-15 9:29 ` Michal Suchánek
2017-06-08 18:00 ` Hari Bathini
2017-06-09 12:04 ` Michal Suchánek
2017-06-20 15:44 ` Hari Bathini
2017-06-26 12:15 ` Michal Suchánek
2017-07-11 18:30 ` Hari Bathini
2017-07-12 11:31 ` msuchanek
2017-07-12 12:15 ` Hari Bathini
2017-05-11 15:07 ` Michal Suchánek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1485f4d-f346-fea6-ee2a-9c7a6b2f6587@linux.vnet.ibm.com \
--to=hbathini@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mahesh@linux.vnet.ibm.com \
--cc=msuchanek@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.