| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [XenPPC] [PATCH] Option to override firmware bootargs
On Mon, 2006-09-18 at 10:28 -0400, Amos Waterland wrote:
> The patch solves a real problem that using GRUB does not. I need to
> boot Xen on a large number of machines (50 or more), and whenever you
> reach that scale you find it necessary to reduce the state of each actor
> in the system.
I see.
> I want to reduce the state saved on each individual machine. I.e, if
> the last person who happened to work on a particular blade happened to
> put a boot argument in the firmware that breaks me, I want to be able to
> override him. I need to boot 50 or more machines at once and I do not
> control the machines, I only get access to them periodically.
Let me see if I can summarize the ways we pass in boot parameters right
now:
- supplied by system firmware in device tree (dom0/Xen parameters)
- hardcoded in Xen source (dom0/Xen)
- supplied as a make argument when building Xen (dom0/Xen)
- added to Xen with a post-processing tool (dom0/Xen)
- compiled into dom0 (dom0 only)
- added to dom0 with a post-processing tool (dom0 only)
Soon we will supply them from GRUB. I'm not yet sure how GRUB passes
dom0 and Xen arguments separately, but it does (on x86).
Any others I've missed? How does each possibility interact with the
others?
I'm happy to accommodate netbooting large clusters, but I'm asking you
to simplify this situation, not make it more complex.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
|
|
| |
|
Home