From: palmer@sifive.com (Palmer Dabbelt)
To: linux-riscv@lists.infradead.org
Subject: [PATCH] RISC-V: Update Kconfig to better handle CMDLINE
Date: Fri, 16 Nov 2018 08:52:18 -0800 (PST) [thread overview]
Message-ID: <mhng-314e946b-3b14-467c-ad23-85983b75cd8d@palmer-si-x1c4> (raw)
In-Reply-To: <20181110010244.5837-1-mick@ics.forth.gr>
On Fri, 09 Nov 2018 17:02:44 PST (-0800), mick at ics.forth.gr wrote:
> Add a menu to chose how the built-in command line will be
> used and add CMDLINE_EXTEND for compatibility with FDT code.
>
> Signed-off-by: Nick Kossifidis <mick@ics.forth.gr>
> ---
> arch/riscv/Kconfig | 45 ++++++++++++++++++++++++---------------------
> 1 file changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 55da93f4e818..81f884164b52 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -227,39 +227,42 @@ endmenu
>
> menu "Boot options"
>
> -config CMDLINE_BOOL
> - bool "Built-in kernel command line"
> +config CMDLINE
> + string "Built-in kernel command line"
> help
> For most platforms, it is firmware or second stage bootloader
> that by default specifies the kernel command line options.
> However, it might be necessary or advantageous to either override
> - the default kernel command line or add a few extra options to it.
> - For such cases, this option allows hardcoding command line options
> - directly into the kernel.
> + the provided kernel command line or add a few extra options to it.
> + For such cases, it is possible to define a built-in command line
> + here and chose how the kernel should use it later on.
>
> - For that, choose 'Y' here and fill in the extra boot parameters
> - in CONFIG_CMDLINE.
> +choice
> + prompt "Built-in command line usage" if CMDLINE != ""
> + default CMDLINE_FALLBACK
> + help
> + Chose how the kernel will handle the provided built-in command
> + line.
>
> - The built-in options will be concatenated to the default command
> - line if CMDLINE_FORCE is set to 'N'. Otherwise, the default
> - command line will be ignored and replaced by the built-in string.
> +config CMDLINE_FALLBACK
> + bool "Fallback"
> + help
> + Use the built-in command line as fallback in case we get nothing
> + from the boot loader.
>
> -config CMDLINE
> - string "Built-in kernel command string"
> - depends on CMDLINE_BOOL
> - default ""
> +config CMDLINE_EXTEND
> + bool "Extension"
> help
> - Supply command-line options at build time by entering them here.
> + Use the built-in command line as an extension of the command line
> + provided by the boot loader.
>
> config CMDLINE_FORCE
> - bool "Built-in command line overrides bootloader arguments"
> - depends on CMDLINE_BOOL
> + bool "Forced"
> help
> - Set this option to 'Y' to have the kernel ignore the bootloader
> - or firmware command line. Instead, the built-in command line
> - will be used exclusively.
> + Use the built-in command line in place of the command line
> + provided by the boot loader.
>
> - If you don't know what to do here, say N.
> +endchoice
>
> endmenu
It looks like this is functionally equivalent to what ARM has, but the polarity
is a bit different and the help strings aren't as easy to read. Is there a
reason we can't just copy what they do?
config CMDLINE
string "Default kernel command string"
default ""
help
On some architectures (EBSA110 and CATS), there is currently no way
for the boot loader to pass arguments to the kernel. For these
architectures, you should supply some command-line options at build
time by entering them here. As a minimum, you should specify the
memory size and the root device (e.g., mem=64M root=/dev/nfs).
choice
prompt "Kernel command line type" if CMDLINE != ""
default CMDLINE_FROM_BOOTLOADER
depends on ATAGS
config CMDLINE_FROM_BOOTLOADER
bool "Use bootloader kernel arguments if available"
help
Uses the command-line options passed by the boot loader. If
the boot loader doesn't provide any, the default kernel command
string provided in CMDLINE will be used.
config CMDLINE_EXTEND
bool "Extend bootloader kernel arguments"
help
The command-line arguments provided by the boot loader will be
appended to the default kernel command string.
config CMDLINE_FORCE
bool "Always use the default kernel command string"
help
Always use the default kernel command string, even if the boot
loader passes other arguments to the kernel.
This is useful if you cannot or don't want to change the
command-line options your boot loader passes to the kernel.
endchoice
I'm not really opposed to your solution, I'm just trying to avoid being
different without a reason.
WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@sifive.com>
To: mick@ics.forth.gr
Cc: mick@ics.forth.gr, linux-riscv@lists.infradead.org,
aou@eecs.berkeley.edu
Subject: Re: [PATCH] RISC-V: Update Kconfig to better handle CMDLINE
Date: Fri, 16 Nov 2018 08:52:18 -0800 (PST) [thread overview]
Message-ID: <mhng-314e946b-3b14-467c-ad23-85983b75cd8d@palmer-si-x1c4> (raw)
Message-ID: <20181116165218.Xnu-LSRbOh9yschVu6SeZ4qdZ3eM7X7ueeLItO2YxF8@z> (raw)
In-Reply-To: <20181110010244.5837-1-mick@ics.forth.gr>
On Fri, 09 Nov 2018 17:02:44 PST (-0800), mick@ics.forth.gr wrote:
> Add a menu to chose how the built-in command line will be
> used and add CMDLINE_EXTEND for compatibility with FDT code.
>
> Signed-off-by: Nick Kossifidis <mick@ics.forth.gr>
> ---
> arch/riscv/Kconfig | 45 ++++++++++++++++++++++++---------------------
> 1 file changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 55da93f4e818..81f884164b52 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -227,39 +227,42 @@ endmenu
>
> menu "Boot options"
>
> -config CMDLINE_BOOL
> - bool "Built-in kernel command line"
> +config CMDLINE
> + string "Built-in kernel command line"
> help
> For most platforms, it is firmware or second stage bootloader
> that by default specifies the kernel command line options.
> However, it might be necessary or advantageous to either override
> - the default kernel command line or add a few extra options to it.
> - For such cases, this option allows hardcoding command line options
> - directly into the kernel.
> + the provided kernel command line or add a few extra options to it.
> + For such cases, it is possible to define a built-in command line
> + here and chose how the kernel should use it later on.
>
> - For that, choose 'Y' here and fill in the extra boot parameters
> - in CONFIG_CMDLINE.
> +choice
> + prompt "Built-in command line usage" if CMDLINE != ""
> + default CMDLINE_FALLBACK
> + help
> + Chose how the kernel will handle the provided built-in command
> + line.
>
> - The built-in options will be concatenated to the default command
> - line if CMDLINE_FORCE is set to 'N'. Otherwise, the default
> - command line will be ignored and replaced by the built-in string.
> +config CMDLINE_FALLBACK
> + bool "Fallback"
> + help
> + Use the built-in command line as fallback in case we get nothing
> + from the boot loader.
>
> -config CMDLINE
> - string "Built-in kernel command string"
> - depends on CMDLINE_BOOL
> - default ""
> +config CMDLINE_EXTEND
> + bool "Extension"
> help
> - Supply command-line options at build time by entering them here.
> + Use the built-in command line as an extension of the command line
> + provided by the boot loader.
>
> config CMDLINE_FORCE
> - bool "Built-in command line overrides bootloader arguments"
> - depends on CMDLINE_BOOL
> + bool "Forced"
> help
> - Set this option to 'Y' to have the kernel ignore the bootloader
> - or firmware command line. Instead, the built-in command line
> - will be used exclusively.
> + Use the built-in command line in place of the command line
> + provided by the boot loader.
>
> - If you don't know what to do here, say N.
> +endchoice
>
> endmenu
It looks like this is functionally equivalent to what ARM has, but the polarity
is a bit different and the help strings aren't as easy to read. Is there a
reason we can't just copy what they do?
config CMDLINE
string "Default kernel command string"
default ""
help
On some architectures (EBSA110 and CATS), there is currently no way
for the boot loader to pass arguments to the kernel. For these
architectures, you should supply some command-line options at build
time by entering them here. As a minimum, you should specify the
memory size and the root device (e.g., mem=64M root=/dev/nfs).
choice
prompt "Kernel command line type" if CMDLINE != ""
default CMDLINE_FROM_BOOTLOADER
depends on ATAGS
config CMDLINE_FROM_BOOTLOADER
bool "Use bootloader kernel arguments if available"
help
Uses the command-line options passed by the boot loader. If
the boot loader doesn't provide any, the default kernel command
string provided in CMDLINE will be used.
config CMDLINE_EXTEND
bool "Extend bootloader kernel arguments"
help
The command-line arguments provided by the boot loader will be
appended to the default kernel command string.
config CMDLINE_FORCE
bool "Always use the default kernel command string"
help
Always use the default kernel command string, even if the boot
loader passes other arguments to the kernel.
This is useful if you cannot or don't want to change the
command-line options your boot loader passes to the kernel.
endchoice
I'm not really opposed to your solution, I'm just trying to avoid being
different without a reason.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-11-16 16:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-10 1:02 [PATCH] RISC-V: Update Kconfig to better handle CMDLINE Nick Kossifidis
2018-11-10 1:02 ` Nick Kossifidis
2018-11-16 16:52 ` Palmer Dabbelt [this message]
2018-11-16 16:52 ` Palmer Dabbelt
2018-11-16 17:08 ` Nick Kossifidis
2018-11-16 17:08 ` Nick Kossifidis
2018-11-16 17:14 ` Nick Kossifidis
2018-11-16 17:14 ` Nick Kossifidis
2018-11-16 17:27 ` Palmer Dabbelt
2018-11-16 17:27 ` Palmer Dabbelt
2018-11-16 17:33 ` Nick Kossifidis
2018-11-16 17:33 ` Nick Kossifidis
-- strict thread matches above, loose matches on Subject: below --
2018-10-04 11:32 Nick Kossifidis
2018-10-04 11:32 ` Nick Kossifidis
2018-11-09 18:34 ` Nick Kossifidis
2018-11-09 18:34 ` Nick Kossifidis
2018-11-09 21:05 ` Palmer Dabbelt
2018-11-09 21:05 ` Palmer Dabbelt
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=mhng-314e946b-3b14-467c-ad23-85983b75cd8d@palmer-si-x1c4 \
--to=palmer@sifive.com \
--cc=linux-riscv@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).