Re: [XenPPC] [PATCH] Option to override firmware bootargs

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Tue, 2006-09-19 at 14:25 -0400, Amos Waterland wrote:
> On Mon, Sep 18, 2006 at 09:51:05AM -0500, Hollis Blanchard wrote:
> > I'm happy to accommodate netbooting large clusters, but I'm asking you
> > to simplify this situation, not make it more complex.
> 
> In order to scale to large clusters, one must have flexible and
> policy-free software.  Right now Xen has a certain policy hard-coded 
> in it: namely, that the firmware-supplied bootargs always take
> precedence over the builtin bootargs with no option to change.  This
> patch is three lines of code, makes Xen more flexible, removes a
> hard-coded policy, and solves a real-world problem.  Seen in that light,
> I hope you will reconsider your objection.

Flexible is nice, I agree, but having too many knobs is bad. This patch
is small, I agree. It's the complexity of *all* the bootargs patches I'm
complaining about. I don't object to your patch; I object to the
situation.

In your cluster environment, you still need to set all your machines to
netboot, right? When doing that, can't you set the boot args at the same
time?

To start simplifying, 'default_bootargs' is empty. So since we have all
these other options, please send me a patch to remove it. That should be
OK, right?

What would be helpful is if you could document the ways we can set boot
args on a wiki page (including a link to the post-processing
__builtin_cmdline tool, etc). Please describe how each option interacts
with the others, e.g. "this is appended to compiled-in arguments", "this
overrides all other arguments", etc. If it's hard for *us* to figure out
the interactions, then we should be asking ourselves if it needs to be
that difficult.

Once we have the list, we can see if it makes sense to simplify further.
For example, we may find it would be easy to make in-binary arguments
*always* override firmware arguments, rather than need this
"bootargs=builtin" option.

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel