I don't really understand the necessity of the /arch.cmd file to be
parsed before /proc/cmdline. It seems simpler to just parse the
program args first before /proc/cmdline. The whole point, as far as I
see, is to composite kernel params based on scripts and/or the
bootloader params. It makes sense to say "arg1=a" should override
(come before) any other arg1, but I see no need to ever need "arg1=a"
to come after other arg1 instances. The only case that may be
necessary is when arg1 supports multiple entries... (i.e. md=*), but
still, I doubt the order would matter. As such, parsing arguments
*after* /proc/cmdline as a necessity seems like a strong edge case to
me. It seems more plausible to parse the command line args before the
kernel cmdline.
On a related note: kinit starts off by creating a composite argv/argc
setup (cmdv/cmdc) with /arch.cmd (see above), then /proc/cmdline, then
argv/argc. While I feel the order should be different, that doesn't
matter here - it seems more logical to pass the entire composite args
to the init= app as well.
Case in point: If I edit grub to boot me into 'S' single user mode, a
simplistic /init script might fail, as that would mean the script
would have to explicitly parse all the run levels out of the kernel
params. Not that this is a complex tast, or anything, but it's
yet-another-step a script writer would have to make. There are
probably other arguments which may be important to init as well...
though I'm speculating.
PS Thanks for the optind fix, I can remove my hackish "optind=1" patch
before all the getopt calls. Heh.
Aaron