[klibc] arch.cmd file and init args

[H. Peter Anvin]

Jim Cromie wrote:
> 
> Posit a given kernel-image, with its /arch.cmd file 'embedded' in it,
> that you need to put on another piece of hardware thats similar, but not 
> identical.
> the arch.cmd held settings that made the kernel boot w/o cmdline 
> additions previously,
> now it needs overridden.
> 
> Thats what I was thinking anyway..  (apologies if I should do it more 
> quietly ;)
> I suppose I see your point - when you constructed that image, it 
> contained what
> it needed in kinit args, not necessarily in /arch.conf.  I guess I dunno..
> 

/arch.cmd isn't meant to be put in a kernel image.  /arch.cmd is there 
to let arch-specific code in the kernel provide platform-specific 
defaults that vary from the usual; currently this is only used on sparc 
(where the defaults come from OpenFirmware variables.)

As far as the ordering of arguments, it's long-standing practice that 
later arguments override earlier arguments on the kernel command line. 
Historically, of course, this is because the kernel command line was 
parsed from left to right setting state variables as it went, but people 
have come to expect this and it's not likely to change.

Thus, the order:

	/arch.cmd		- platform-provided defaults
	/proc/cmdline		- bootloader-specified commands
	kinit command line	- overrides provided by initramfs s/w

Note that the kinit command line options are only recognized after a 
"--" to avoid problems.

I'm more than willing to discuss additional support, as needed; however, 
the rule that "late overrides earlier" was set in stone many years ago 
and will obviously not be changed.

Alternatives to /arch.cmd and /proc/cmdline could be the init process 
environment, for example; however, that does require more invasive 
kernel changes.  However, if there is a strong reason to do it 
differently, now is the time to speak up.

	-hpa