x86 built-in command line (resend)
PATCH 1/1 x86 built-in command line (resend)
I'm resending this as-is because the earlier thread petered out without any strong arguments against this approach. x86_64 patch to follow.
Allow setting the kernel command line at compile time on x86.
arch/i386/Kconfig +14 -0
@@ -830,6 +830,20 @@ config COMPAT_VDSO If unsure, say Y. +config CMDLINE_BOOL + bool "Default bootloader kernel arguments" if EMBEDDED + +config CMDLINE + string "Initial kernel command string" if EMBEDDED + depends on CMDLINE_BOOL + default "root=/dev/hda1 ro" + help + On some systems, there is no way for the boot loader to pass + arguments to the kernel. For these platforms, you can supply + some command-line options at build time by entering them + here. In most cases you will need to specify the root device + here. + endmenu config ARCH_ENABLE_MEMORY_HOTPLUG
arch/i386/kernel/setup.c +4 -0
@@ -723,6 +723,10 @@ static void __init parse_cmdline_early (int len =0 ;int userdef =0 ; +#ifdef CONFIG_CMDLINE_BOOL +strlcpy (saved_command_line,CONFIG_CMDLINE ,COMMAND_LINE_SIZE ); +#endif +/* Save unparsed command line copy for /proc/cmdline */ saved_command_line[COMMAND_LINE_SIZE -1 ] ='\0' ;
Signature · 1 line
Mathematics is the supreme nostalgia of our time.
Hi,
arch/i386/Kconfig config COMPAT_VDSO · line 834
Quoted 2 lines · Matt Mackall
arch/i386/Kconfig +2
-0+config CMDLINE_BOOL + bool "Default bootloader kernel arguments" if EMBEDDED
You can use a normal depends line here instead of the if.
arch/i386/Kconfig config COMPAT_VDSO · line 839
Quoted 4 lines
arch/i386/Kconfig +4
-0+config CMDLINE + string "Initial kernel command string" if EMBEDDED + depends on CMDLINE_BOOL + default "root=/dev/hda1 ro"
This would cause CMDLINE always be set and the simple dependency on CMDLINE_BOOL should be enough, so that...
arch/i386/kernel/setup.c static void __init parse_cmdline_early ( · line 728
Quoted 3 lines
arch/i386/kernel/setup.c +3
-0+#ifdef CONFIG_CMDLINE_BOOL +strlcpy (saved_command_line,CONFIG_CMDLINE ,COMMAND_LINE_SIZE ); +#endif
...you only have to test and use CONFIG_CMDLINE here.
bye, Roman
Quoted 3 lines · Matt Mackall
I'm resending this as-is because the earlier thread petered out without any strong arguments against this approach.
x86_64patch to follow.
"No strong arguments?"
I still maintain that this patch has the wrong priority in case more than one set of arguments are provided.
-hpa
Quoted 9 lines · H. Peter Anvin
Quoted 3 lines · Matt Mackall
I'm resending this as-is because the earlier thread petered out without any strong arguments against this approach.
x86_64patch to follow."No strong arguments?"
I still maintain that this patch has the wrong priority in case more than one set of arguments are provided.
But you still haven't answered how that lets you work around firmware that passes parameters you don't like.
Signature · 1 line
Mathematics is the supreme nostalgia of our time.
Quoted 5 lines · Matt Mackall
Quoted 4 lines · H. Peter Anvin
Quoted 3 lines · Matt Mackall
I'm resending this as-is because the earlier thread petered out without any strong arguments against this approach.
x86_64patch to follow.
Quoted 7 lines
Quoted 3 lines
"No strong arguments?"
I still maintain that this patch has the wrong priority in case more than one set of arguments are provided.
But you still haven't answered how that lets you work around firmware that passes parameters you don't like.
That a fairly unique problem, and is most likely in a minority application. For that case a CONFIG option to ignore the firmware-provided command line would make sense. I do not believe it should be the only option or even the default.
It would be particularly good if this could be standardized across architectures, which is another reason to do it right.
-hpa
Quoted 11 lines · H. Peter Anvin
Quoted 10 lines · Matt Mackall
Quoted 8 lines · H. Peter Anvin
Quoted 3 lines · Matt Mackall
I'm resending this as-is because the earlier thread petered out without any strong arguments against this approach.
x86_64patch to follow."No strong arguments?"
I still maintain that this patch has the wrong priority in case more than one set of arguments are provided.
Quoted 8 lines
Quoted 3 lines
But you still haven't answered how that lets you work around firmware that passes parameters you don't like.
That a fairly unique problem, and is most likely in a minority application. For that case a CONFIG option to ignore the firmware-provided command line would make sense. I do not believe it should be the only option or even the default.
It's not the default. The default is all args come from the bootloader.
At the risk of repeating myself, here are all possible features and behaviors carefully enumerated again:
Possible features:
a) allow dealing with bootloaders that don't pass arguments
b) allow dealing with bootloaders that pass bogus arguments
c) allow dealing with bootloaders that run up against length limits
d) allow dealing with bootloaders where changing arguments dynamically is difficult
e) provide friendly defaults
Possible behaviors:
1) command line overrides built-in (won't work with b, works with the rest)
2) built-in overrides command line (not so great for e, works with the rest)
3) command line appends to built-in (generally broken as our command parser can't arbitrarily override earlier arguments in most cases)
4) built-in appends to command line (same story)
Now I basically think behavior (e) is worthless. Embedded folks don't care if the kernel's friendly and it's a solved problem for distros too. Anyone else is building a kernel for themselves and don't need defaults.
By comparison, the value of (b) is that you can control things you otherwise can't.
Quoted 2 lines
It would be particularly good if this could be standardized across architectures, which is another reason to do it right.
Yes. They should all clearly do (2).
Signature · 1 line
Mathematics is the supreme nostalgia of our time.