[klibc] arch.cmd file and init args

[Jim Cromie]

Aaron Griffin wrote:
> On 6/6/06, Jim Cromie <jim.cromie at gmail.com> wrote:
>> Aaron Griffin wrote:
>> > 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.
>> Why not ?  wouldnt it make sense to preserve the override capability of
>> cmdline,
>> instead of assuming you get it all right the 1st time ?
> I'm not sure what you mean.  My rationale is that, if you want an
> override arg, pass it as a param to kinit, if not, don't pass it at
> all.  I don't see the need to spit this information to a file.
>
>> override allows sub-arch variations, eventually evolving to the right
>> arch.cmd
>> content for each given platform.
> I don't know what you mean by this - can you elaborate?
>

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