[PATCH] x86 built-in command line (resend)

[PATCH] x86 built-in command line (resend)

[Matt Mackall]

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.

Signed-off-by: Matt Mackall <mpm@selenic.com>

Index: linux/arch/i386/Kconfig
===================================================================
--- linux.orig/arch/i386/Kconfig	2006-07-26 18:08:28.000000000 -0500
+++ linux/arch/i386/Kconfig	2006-07-27 16:09:13.000000000 -0500
@@ -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
Index: linux/arch/i386/kernel/setup.c
===================================================================
--- linux.orig/arch/i386/kernel/setup.c	2006-07-26 18:08:28.000000000 -0500
+++ linux/arch/i386/kernel/setup.c	2006-07-27 16:09:13.000000000 -0500
@@ -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';
 


-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line (resend)

[Roman Zippel]

Hi,

On Mon, 31 Jul 2006, Matt Mackall wrote:

> +config CMDLINE_BOOL
> +	bool "Default bootloader kernel arguments" if EMBEDDED

You can use a normal depends line here instead of the if.

> +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...

> +#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

Re: [PATCH] x86 built-in command line (resend)

[H. Peter Anvin]

Matt Mackall wrote:
> I'm resending this as-is because the earlier thread petered out
> without any strong arguments against this approach. x86_64 patch 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

Re: [PATCH] x86 built-in command line (resend)

[Matt Mackall]

On Mon, Jul 31, 2006 at 12:07:02PM -0700, H. Peter Anvin wrote:
> Matt Mackall wrote:
> >I'm resending this as-is because the earlier thread petered out
> >without any strong arguments against this approach. x86_64 patch 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.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line (resend)

[H. Peter Anvin]

Matt Mackall wrote:
> On Mon, Jul 31, 2006 at 12:07:02PM -0700, H. Peter Anvin wrote:
>> Matt Mackall wrote:
>>> I'm resending this as-is because the earlier thread petered out
>>> without any strong arguments against this approach. x86_64 patch 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.
> 

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

Re: [PATCH] x86 built-in command line (resend)

[Matt Mackall]

On Mon, Jul 31, 2006 at 12:35:16PM -0700, H. Peter Anvin wrote:
> Matt Mackall wrote:
> >On Mon, Jul 31, 2006 at 12:07:02PM -0700, H. Peter Anvin wrote:
> >>Matt Mackall wrote:
> >>>I'm resending this as-is because the earlier thread petered out
> >>>without any strong arguments against this approach. x86_64 patch 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.
> >
> 
> 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. 

> 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).

-- 
Mathematics is the supreme nostalgia of our time.