[klibc] arch.cmd file and init args

Aaron Griffin aaronmgriffin at gmail.com
Tue Jun 6 16:43:26 PDT 2006


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



More information about the klibc mailing list