[PATCH] x86 built-in command line

[PATCH] x86 built-in command line

[Matt Mackall]

This patch allows building in a kernel command line on x86 as is
possible on several other arches.

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

Index: linux/arch/i386/Kconfig
===================================================================
--- linux.orig/arch/i386/Kconfig	2006-05-26 16:18:13.000000000 -0500
+++ linux/arch/i386/Kconfig	2006-06-11 17:01:01.000000000 -0500
@@ -763,6 +763,20 @@ config HOTPLUG_CPU
 	  /sys/devices/system/cpu.
 
 
+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
 
 
Index: linux/arch/i386/kernel/setup.c
===================================================================
--- linux.orig/arch/i386/kernel/setup.c	2006-05-26 16:18:13.000000000 -0500
+++ linux/arch/i386/kernel/setup.c	2006-06-11 16:23:51.000000000 -0500
@@ -713,6 +713,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

[Jesper Juhl]

On 11/06/06, Matt Mackall <mpm@selenic.com> wrote:
[snip]
> +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.

Perhaps "In most cases you will need to specify at least the root
device here." ???

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH] x86 built-in command line

[Jan Engelhardt]

>
>This patch allows building in a kernel command line on x86 as is
>possible on several other arches.
>
>+config CMDLINE
>+	  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.

Thank God x86 does not have that limitation. Or am I missing some exotic 
bootloader that fails to pass in arguments?


Jan Engelhardt
-- 

Re: [PATCH] x86 built-in command line

[Matt Mackall]

On Mon, Jun 12, 2006 at 01:30:27AM +0200, Jan Engelhardt wrote:
> >
> >This patch allows building in a kernel command line on x86 as is
> >possible on several other arches.
> >
> >+config CMDLINE
> >+	  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.
> 
> Thank God x86 does not have that limitation. Or am I missing some exotic 
> bootloader that fails to pass in arguments?

Yes. Note that this depends on CONFIG_EMBEDDED. It's quite common for
embedded apps to roll their own trivial ROM-based boot loaders. It's
also quite common for embedded boxen to run up against the command
line length limit that's hardcoded in the boot protocol.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line

[H. Peter Anvin]

Followup to:  <20060611234746.GJ24227@waste.org>
By author:    Matt Mackall <mpm@selenic.com>
In newsgroup: linux.dev.kernel
>
> On Mon, Jun 12, 2006 at 01:30:27AM +0200, Jan Engelhardt wrote:
> > >
> > >This patch allows building in a kernel command line on x86 as is
> > >possible on several other arches.
> > >
> > >+config CMDLINE
> > >+	  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.
> > 
> > Thank God x86 does not have that limitation. Or am I missing some exotic 
> > bootloader that fails to pass in arguments?
> 
> Yes. Note that this depends on CONFIG_EMBEDDED. It's quite common for
> embedded apps to roll their own trivial ROM-based boot loaders. It's
> also quite common for embedded boxen to run up against the command
> line length limit that's hardcoded in the boot protocol.
> 

There is no command line length limit hard-coded in the boot protocol
per se (at least not for version 2.02 or higher.)  The length limit is
hard-coded in the *kernel*, not in the protocol.

	-hpa

Re: [PATCH] x86 built-in command line

[Arjan van de Ven]

On Sun, 2006-06-11 at 16:55 -0500, Matt Mackall wrote:
> This patch allows building in a kernel command line on x86 as is
> possible on several other arches.


wouldn't it make more sense to allow the initramfs to set such arguments
instead?

Re: [PATCH] x86 built-in command line

[Matt Mackall]

On Mon, Jun 12, 2006 at 01:40:41AM +0200, Arjan van de Ven wrote:
> On Sun, 2006-06-11 at 16:55 -0500, Matt Mackall wrote:
> > This patch allows building in a kernel command line on x86 as is
> > possible on several other arches.
> 
> wouldn't it make more sense to allow the initramfs to set such arguments
> instead?

Huh?

Are you suggesting we go digging around in a gzipped initramfs image at
early command line parsing time? I can't really see how that would work. 

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line

[Arjan van de Ven]

On Sun, 2006-06-11 at 18:51 -0500, Matt Mackall wrote:
> On Mon, Jun 12, 2006 at 01:40:41AM +0200, Arjan van de Ven wrote:
> > On Sun, 2006-06-11 at 16:55 -0500, Matt Mackall wrote:
> > > This patch allows building in a kernel command line on x86 as is
> > > possible on several other arches.
> > 
> > wouldn't it make more sense to allow the initramfs to set such arguments
> > instead?
> 
> Huh?
> 
> Are you suggesting we go digging around in a gzipped initramfs image at
> early command line parsing time? I can't really see how that would work. 

but.. the example you give is for the rootfs.. which is used only really
late...

Re: [PATCH] x86 built-in command line

[Matt Mackall]

On Mon, Jun 12, 2006 at 02:08:18AM +0200, Arjan van de Ven wrote:
> On Sun, 2006-06-11 at 18:51 -0500, Matt Mackall wrote:
> > On Mon, Jun 12, 2006 at 01:40:41AM +0200, Arjan van de Ven wrote:
> > > On Sun, 2006-06-11 at 16:55 -0500, Matt Mackall wrote:
> > > > This patch allows building in a kernel command line on x86 as is
> > > > possible on several other arches.
> > > 
> > > wouldn't it make more sense to allow the initramfs to set such arguments
> > > instead?
> > 
> > Huh?
> > 
> > Are you suggesting we go digging around in a gzipped initramfs image at
> > early command line parsing time? I can't really see how that would work. 
> 
> but.. the example you give is for the rootfs.. which is used only really
> late...

That's not an example, that's just pointing out if you don't specify
root=, it probably won't boot.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line

[Willy Tarreau]

On Sun, Jun 11, 2006 at 08:38:01PM -0500, Matt Mackall wrote:
> On Mon, Jun 12, 2006 at 02:08:18AM +0200, Arjan van de Ven wrote:
> > On Sun, 2006-06-11 at 18:51 -0500, Matt Mackall wrote:
> > > On Mon, Jun 12, 2006 at 01:40:41AM +0200, Arjan van de Ven wrote:
> > > > On Sun, 2006-06-11 at 16:55 -0500, Matt Mackall wrote:
> > > > > This patch allows building in a kernel command line on x86 as is
> > > > > possible on several other arches.
> > > > 
> > > > wouldn't it make more sense to allow the initramfs to set such arguments
> > > > instead?
> > > 
> > > Huh?
> > > 
> > > Are you suggesting we go digging around in a gzipped initramfs image at
> > > early command line parsing time? I can't really see how that would work. 
> > 
> > but.. the example you give is for the rootfs.. which is used only really
> > late...
> 
> That's not an example, that's just pointing out if you don't specify
> root=, it probably won't boot.

I've had other usages of this : when booting kernels from PXE, it is
very convenient to have default command line arguments in different
images, and not have to modify anything in the boot loader. Moreover,
using a *default* command line allows the boot loader to override the
arguments while it would not be easy from the initramfs. Last but not
least, disabling sensible features such as ACPI/APIC needs to be
performed before initramfs.

Cheers,
Willy

Re: [PATCH] x86 built-in command line

[H. Peter Anvin]

Followup to:  <20060611235101.GK24227@waste.org>
By author:    Matt Mackall <mpm@selenic.com>
In newsgroup: linux.dev.kernel
>
> On Mon, Jun 12, 2006 at 01:40:41AM +0200, Arjan van de Ven wrote:
> > On Sun, 2006-06-11 at 16:55 -0500, Matt Mackall wrote:
> > > This patch allows building in a kernel command line on x86 as is
> > > possible on several other arches.
> > 
> > wouldn't it make more sense to allow the initramfs to set such arguments
> > instead?
> 
> Huh?
> 
> Are you suggesting we go digging around in a gzipped initramfs image at
> early command line parsing time? I can't really see how that would work. 
> 

You can append to it without unzipping it.  It's probably the wrong
thing for this, though, since there are numerous stages of kernel
initialization which don't have access to the initramfs.

	-hpa

Re: [PATCH] x86 built-in command line

[Andi Kleen]

Matt Mackall <mpm@selenic.com> writes:

> This patch allows building in a kernel command line on x86 as is
> possible on several other arches.

I'm surprised you didn't do the obvious "tiny" changes associated with
that. Look at the static array sizes of the command line buffers.

-Andi

Re: [PATCH] x86 built-in command line

[Matt Mackall]

On Mon, Jun 12, 2006 at 10:11:24AM +0200, Andi Kleen wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
> > This patch allows building in a kernel command line on x86 as is
> > possible on several other arches.
> 
> I'm surprised you didn't do the obvious "tiny" changes associated with
> that. Look at the static array sizes of the command line buffers.

They're not entirely obvious. The saved command line buffer size is
currently fixed so if we set a default that's larger, we'd like to
have a compile failure if it's too large.

Next step here is to make the buffer size configurable, which will
allow people to use command lines longer (or shorter!) than the boot
protocol allows (256 bytes on x86).

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line

[H. Peter Anvin]

Followup to:  <20060612143748.GN24227@waste.org>
By author:    Matt Mackall <mpm@selenic.com>
In newsgroup: linux.dev.kernel
>
> On Mon, Jun 12, 2006 at 10:11:24AM +0200, Andi Kleen wrote:
> > Matt Mackall <mpm@selenic.com> writes:
> > 
> > > This patch allows building in a kernel command line on x86 as is
> > > possible on several other arches.
> > 
> > I'm surprised you didn't do the obvious "tiny" changes associated with
> > that. Look at the static array sizes of the command line buffers.
> 
> They're not entirely obvious. The saved command line buffer size is
> currently fixed so if we set a default that's larger, we'd like to
> have a compile failure if it's too large.
> 
> Next step here is to make the buffer size configurable, which will
> allow people to use command lines longer (or shorter!) than the boot
> protocol allows (256 bytes on x86).
> 

The boot protocol 256-byte limitation applies only to protocol version
2.01 or earlier.  After that, there is still a 256-byte *KERNEL*
limitation, but it is not a *PROTOCOL* limitation.  In other words,
the kernel can, and should be, upgraded; in fact, a gentleman by the
name of Alon Bar-Lev has submitted that patch several times already;
it wasn't accepted because of an unsubstantiated report that it broke
LILO, the veracity of which I think is in serious doubt.

	-hpa

Re: [PATCH] x86 built-in command line

[H. Peter Anvin]

Followup to:  <20060611215530.GH24227@waste.org>
By author:    Matt Mackall <mpm@selenic.com>
In newsgroup: linux.dev.kernel
>
> This patch allows building in a kernel command line on x86 as is
> possible on several other arches.
> 
> Index: linux/arch/i386/kernel/setup.c
> ===================================================================
> --- linux.orig/arch/i386/kernel/setup.c	2006-05-26 16:18:13.000000000 -0500
> +++ linux/arch/i386/kernel/setup.c	2006-06-11 16:23:51.000000000 -0500
> @@ -713,6 +713,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';
>  

NAK.

a. Please make the patch available for x86-64 as well as x86.  The two
are coupled enough that they need to agree.

b. This patch will override a user-provided command line if one
exists.  This is the wrong behaviour; instead, the builtin command
line should only apply if no user-specified command line is present.

	-hpa

Re: [PATCH] x86 built-in command line

[Michael Buesch]

On Monday 12 June 2006 19:12, H. Peter Anvin wrote:
> > +#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';
> >  
> 
> NAK.
> 
> a. Please make the patch available for x86-64 as well as x86.  The two
> are coupled enough that they need to agree.
> 
> b. This patch will override a user-provided command line if one
> exists.  This is the wrong behaviour; instead, the builtin command
> line should only apply if no user-specified command line is present.

I would say a user supplied cmd line should be appended to the
built-in cmd line.

-- 
Greetings Michael.

Re: [PATCH] x86 built-in command line

[H. Peter Anvin]

Michael Buesch wrote:
>>
>> a. Please make the patch available for x86-64 as well as x86.  The two
>> are coupled enough that they need to agree.
>>
>> b. This patch will override a user-provided command line if one
>> exists.  This is the wrong behaviour; instead, the builtin command
>> line should only apply if no user-specified command line is present.
> 
> I would say a user supplied cmd line should be appended to the
> built-in cmd line.
> 

That's another option; going with the "later wins" rule.  However, there is a problem with 
this, and that is that the total length can end up being very long.

	-hpa

Re: [PATCH] x86 built-in command line

[Tim Bird]

H. Peter Anvin wrote:
> b. This patch will override a user-provided command line if one
> exists.  This is the wrong behaviour; instead, the builtin command
> line should only apply if no user-specified command line is present.

I'd prefer that the kernel default command line was appended
to the user-supplied one, instead of replacing it. (Or vice-versa.)
This way I can leave the user-specified command line empty and
get the behaviour described above.  Or, I can choose a few
specific options to come from the bootloader and have others
come from the default command line (in the kernel).

I'm VERY interested in this feature, for purposes of automated
testing on multiple architectures.  I have a test rig that can easily
set the command line at kernel compilation time.  However,
coming up with a mechanism to control command line options on
multiple different bootloaders, for the variety of embedded platforms
I deal with, is very difficult.  Right now this part of my
test rig works on all popular embedded arches except x86.

Eventually, I'd like to automatically test many different
kernel command line options, on multiple platforms.


Regards,
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: [PATCH] x86 built-in command line

[Matt Mackall]

On Mon, Jun 12, 2006 at 10:12:47AM -0700, H. Peter Anvin wrote:
> Followup to:  <20060611215530.GH24227@waste.org>
> By author:    Matt Mackall <mpm@selenic.com>
> In newsgroup: linux.dev.kernel
> >
> > This patch allows building in a kernel command line on x86 as is
> > possible on several other arches.
> > 
> > Index: linux/arch/i386/kernel/setup.c
> > ===================================================================
> > --- linux.orig/arch/i386/kernel/setup.c	2006-05-26 16:18:13.000000000 -0500
> > +++ linux/arch/i386/kernel/setup.c	2006-06-11 16:23:51.000000000 -0500
> > @@ -713,6 +713,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';
> >  
> 
> NAK.
> 
> a. Please make the patch available for x86-64 as well as x86.  The two
> are coupled enough that they need to agree.

I don't think that's a show-stopper. I'll provide one after we decide
how this should work.
 
> b. This patch will override a user-provided command line if one
> exists.  This is the wrong behaviour; instead, the builtin command
> line should only apply if no user-specified command line is present.

There are four possible behaviors:

a) internal supercedes external (what's in the patch)
b) external supercedes internal (what you proposed)
c) external is appended to internal (what Tim proposed)
d) internal is appended to external (not very interesting)

And there are some possible uses:

1) bootloader doesn't support command line
2) bootloader has hardcoded or otherwise difficult-to-change command line
3) automated testing for tftp boot, etc.
4) bypassing boot protocol command line length (not yet supported)
5) setting defaults like ACPI off, etc.

(a) works for 1, 2, 3, and 4.
(b) works for 1, 3, and 4, provided you clear the command line in your
boot loader
(c) works for 1, 3, and 4, provided you're not trying to override
earlier arguments

(5) generally is unworkable because our parser doesn't generally do the
right thing for options like "acpi=on acpi=off" (though it might work
in the specific case of acpi, haven't checked). If, for instance, you
try to override console, you'll get two consoles.

So I think (a) is the way to go. If there's a use case for (b) that's
important, it's not jumping out at me. Finally, at least the arch I
inspected when preparing this patch had gone with (a) too.

(As an example of (2), the last x86 bootloader I dealt with was written
in Forth, and getting a fresh build of it meant getting some cycles
from the last two Forth hackers on the planet.)

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH] x86 built-in command line

[Thomas Gleixner]

On Mon, 2006-06-12 at 15:49 -0500, Matt Mackall wrote:
> I don't think that's a show-stopper. I'll provide one after we decide
> how this should work.
>  
> > b. This patch will override a user-provided command line if one
> > exists.  This is the wrong behaviour; instead, the builtin command
> > line should only apply if no user-specified command line is present.
> 
> There are four possible behaviors:
> 
> a) internal supercedes external (what's in the patch)
> b) external supercedes internal (what you proposed)
> c) external is appended to internal (what Tim proposed)
> d) internal is appended to external (not very interesting)
> 
> And there are some possible uses:
> 
> 1) bootloader doesn't support command line
> 2) bootloader has hardcoded or otherwise difficult-to-change command line
> 3) automated testing for tftp boot, etc.
> 4) bypassing boot protocol command line length (not yet supported)
> 5) setting defaults like ACPI off, etc.
> 
> (a) works for 1, 2, 3, and 4.
> (b) works for 1, 3, and 4, provided you clear the command line in your
> boot loader
> (c) works for 1, 3, and 4, provided you're not trying to override
> earlier arguments
> 
> (5) generally is unworkable because our parser doesn't generally do the
> right thing for options like "acpi=on acpi=off" (though it might work
> in the specific case of acpi, haven't checked). If, for instance, you
> try to override console, you'll get two consoles.
> 
> So I think (a) is the way to go. If there's a use case for (b) that's
> important, it's not jumping out at me. Finally, at least the arch I
> inspected when preparing this patch had gone with (a) too.
> 
> (As an example of (2), the last x86 bootloader I dealt with was written
> in Forth, and getting a fresh build of it meant getting some cycles
> from the last two Forth hackers on the planet.)

Well most of the bootloaders I'm working with let me change the
commandline. So why must I recompile the kernel to change the console
from VGA to serial ? Having a default commandline built in is great,
when

- your bootloader is not able to provide one 
- as a default fallback if the operator(me) was too lazy to setup the
bootloader 

	tglx

Re: [PATCH] x86 built-in command line

[Tim Bird]

Thomas Gleixner wrote:
> Well most of the bootloaders I'm working with let me change the
> commandline. 

Just FYI for this thread, most of the bootloaders I work with
don't let me change the kernel command line.  Many have no
knowledge of Linux whatsoever.  Many boards, especially internal
boards, have hobbled-together custom bootloaders.

Hence, I've gotten out of the habit of figuring out how to set
the command line args from the bootloader even for those
platforms where the bootloader *is* capable of it.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: [PATCH] x86 built-in command line

[Thomas Gleixner]

On Mon, 2006-06-12 at 14:36 -0700, Tim Bird wrote:
> Thomas Gleixner wrote:
> > Well most of the bootloaders I'm working with let me change the
> > commandline. 
> 
> Just FYI for this thread, most of the bootloaders I work with
> don't let me change the kernel command line.  Many have no
> knowledge of Linux whatsoever.  Many boards, especially internal
> boards, have hobbled-together custom bootloaders.
> 
> Hence, I've gotten out of the habit of figuring out how to set
> the command line args from the bootloader even for those
> platforms where the bootloader *is* capable of it.

Which is not a problem with the (b) variant where the bootloader
provided command line replaces the compiled in one. It does not change
your habit of not setting up a commandline - or an empty one. 

This would also ensure compability with grub and friends, which I
consider as a real strong argument to avoid breakage all over the place.

	tglx
 

Re: [PATCH] x86 built-in command line

[Tim Bird]

Thomas Gleixner wrote:
> This would also ensure compability with grub and friends, which I
> consider as a real strong argument to avoid breakage all over the place.

In any of the cases, wouldn't you have to set the option in order
to break something?
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: [PATCH] x86 built-in command line

[Randy.Dunlap]

On Mon, 12 Jun 2006 15:49:25 -0500 Matt Mackall wrote:

> On Mon, Jun 12, 2006 at 10:12:47AM -0700, H. Peter Anvin wrote:
> > Followup to:  <20060611215530.GH24227@waste.org>
> > By author:    Matt Mackall <mpm@selenic.com>
> > In newsgroup: linux.dev.kernel
> > >
> > > This patch allows building in a kernel command line on x86 as is
> > > possible on several other arches.
> > > 
> > > Index: linux/arch/i386/kernel/setup.c
> > > ===================================================================
> > > --- linux.orig/arch/i386/kernel/setup.c	2006-05-26 16:18:13.000000000 -0500
> > > +++ linux/arch/i386/kernel/setup.c	2006-06-11 16:23:51.000000000 -0500
> > > @@ -713,6 +713,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';
> > >  
> > 
> > NAK.
> > 
> > a. Please make the patch available for x86-64 as well as x86.  The two
> > are coupled enough that they need to agree.
> 
> I don't think that's a show-stopper. I'll provide one after we decide
> how this should work.
>  
> > b. This patch will override a user-provided command line if one
> > exists.  This is the wrong behaviour; instead, the builtin command
> > line should only apply if no user-specified command line is present.
> 
> There are four possible behaviors:
> 
> a) internal supercedes external (what's in the patch)
> b) external supercedes internal (what you proposed)
> c) external is appended to internal (what Tim proposed)
> d) internal is appended to external (not very interesting)

where internal ::= the new CONFIG_CMDLINE option ?
  and external  ::= what a user can add via a boot loader ?


> And there are some possible uses:
> 
> 1) bootloader doesn't support command line
> 2) bootloader has hardcoded or otherwise difficult-to-change command line
> 3) automated testing for tftp boot, etc.
> 4) bypassing boot protocol command line length (not yet supported)
> 5) setting defaults like ACPI off, etc.
> 
> (a) works for 1, 2, 3, and 4.
> (b) works for 1, 3, and 4, provided you clear the command line in your
> boot loader
> (c) works for 1, 3, and 4, provided you're not trying to override
> earlier arguments
> 
> (5) generally is unworkable because our parser doesn't generally do the
> right thing for options like "acpi=on acpi=off" (though it might work
> in the specific case of acpi, haven't checked). If, for instance, you
> try to override console, you'll get two consoles.
> 
> So I think (a) is the way to go. If there's a use case for (b) that's
> important, it's not jumping out at me. Finally, at least the arch I
> inspected when preparing this patch had gone with (a) too.

I frequently override command line options.  I guess I have no
use for this patch.

> (As an example of (2), the last x86 bootloader I dealt with was written
> in Forth, and getting a fresh build of it meant getting some cycles
> from the last two Forth hackers on the planet.)

That's not helping your argument IMO.

---
~Randy

Re: [PATCH] x86 built-in command line

[Tim Bird]

Randy.Dunlap wrote:
> I frequently override command line options.  I guess I have no
> use for this patch.

Randy,

Do you override the complete command line or individual boot args?
On what platform(s)?

Thanks - just trying to learn other people's situations...
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: [PATCH] x86 built-in command line

[Randy.Dunlap]

On Mon, 12 Jun 2006 15:00:31 -0700 Tim Bird wrote:

> Randy.Dunlap wrote:
> > I frequently override command line options.  I guess I have no
> > use for this patch.
> 
> Randy,
> 
> Do you override the complete command line or individual boot args?
> On what platform(s)?

I probably should say I "append" to the command line instead of
"override" it.
On i386 and x86_64.

> Thanks - just trying to learn other people's situations...

---
~Randy