Re: [PATCH] Provide mechanism for editing builtin command-line in zImage binary.

[Michal Ostrowski <mostrows@watson.ibm.com>]

On Tue, 2006-05-30 at 13:41 -0700, Mark A. Greer wrote:
> On Mon, May 29, 2006 at 10:01:03PM -0400, mostrows@watson.ibm.com wrote:
> > zImage will store the builtin command-line in a dedicated section, allowing
> > it to be easily identified and edited with user-space tools.
> >
> > zImage will set /chosen/bootargs to the stored builtin command-line setting,
> > if /chosen/bootargs is empty (emulating the behavior in prom_init.c).
> > 
> > Use of this mechanism avoids the need to modify firmware or rely on a
> > bootloader to customize kernel arguments (and overall system
> > behavior).  The command line can be edited as needed when a zImage is
> > copied to a TFTP staging area for download by firmware.




> Why do this?  Why not get rid of storing the cmdline in the zImage altogether?  
> 

The CONFIG_CMDLINE that we have now is very useful if I want the
behavior of the system to be dependent on the kernel/command line I
specify that it used (particularly in BOOTP/TFTP scenarios).  For such
systems I configure their firmware to not provide any arguments and to
always download via TFTP a designated kernel image.

What this scenario does, is it allows me to specify system behavior by
putting the right kernel with the right command line in the magic
location from where it will be downloaded.

The problem is, that if I have some large number of machines and I want
to use the same kernel for all of them (and simply change the command
line between them) then I have to effectively build a custom kernel for
each.  This patch allows me to build one kernel and then simply edit the
command line embedded within it.

The key point is that the command line changes and I don't want to have
to require a firmware interaction every time I change it.



> We already have equivalent functionality by storing it in the dt's
> /chosen/bootargs so why this unnecessary complexity?
> 


> Add some code to edit the /chosen/bootargs at zImage runtime (just like
> arch/ppc used to) and we're covered.

That is what this patch is doing.

>   AFAICT, we're already adding a tool
> to tack on flat dt's to an already existing zImage so you're not doing
> anything we can't--or won't--do already.
> 

Can you please point me at this code so that I can evaluate it in
detail?

I'm curious how the tacked-on dt is expected to interact with the real
FW dt, and in particular how you would expect the interrogation
of /chosen/bootargs in prom_init.c (using prom_getprop()) to pick up the
command line value I specify in the tacked-on dt.


-- 
Michal Ostrowski <mostrows@watson.ibm.com>