On Mon, Jun 19, 2006 at 11:13:35AM -0400, Jimi Xenidis wrote:
> On Jun 17, 2006, at 12:06 AM, Amos Waterland wrote:
> > Since prom_init is not executed by Linux when running as a guest in Xen,
This was bogus: prom_init is indeed executed. Please see the new patch below.
> BTW: the Xen passes the string after "--" in bootargs to Dom0
Yes, I am aware of that. But doesn't that mean that if I have a cluster
composed of hundreds of blades I would have to configure the NFS root
mount of their DOM0 via the firmware of each blade? That is, wouldn't I
have to get physical access to the machine and manually run this?
=> setenv bootargs
'xenarg=foo -- root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off'
If I needed to temporarily change the NFS path for fifty of the blades,
it would be really nice to be able to do that in an automated way.
A patch just went into Paulus' tree that allows you to have a single
zImage for an arbitrary number of compatible machines: you just run a
script to write new boot arguments into a buffer in the zImage. A
similar patch could certainly be constructed for Xen. This is nice for
ten machines, but since you really should copy the kernel before editing
it, you end up with hundreds of binaries sitting around whose only
difference is boot arguments. That is, the same situation you would
have been in had you just written a script to edit the .config and
compiled a hundred times.
So one could argue that the right way to do this is to extend SLOF to
be able to get boot arguments from the DHCP server using a DHCP extension.
But the fact is: right now on real hardware with existing SLOF, Linux on
Xen cannot in an automated way do a NFS root mount. The reason for this
is that Xen hard-codes a value (console=ttyS0) into bootargs, which
makes Linux in prom_init ignore its own builtin command line and use
only what Xen provided.
The below patch makes Linux support a builtin=override option, which
works and lets me do an NFS root mount. I do not think it is the right
solution, but I am posting it for comment.
I would rather just rip out the code in Xen that hardcodes the console
argument and put that argument in CONFIG_CMDLINE in xen_maple_defconfig
instead.
Signed-off-by: Amos Waterland <apw@xxxxxxxxxx>
---
prom.c | 9 +++++++++
prom_init.c | 8 ++++++++
2 files changed, 17 insertions(+)
diff -r 6f3d44537b76 arch/powerpc/kernel/prom.c
--- a/arch/powerpc/kernel/prom.c Fri Jun 16 16:07:38 2006 -0500
+++ b/arch/powerpc/kernel/prom.c Tue Jun 20 03:28:06 2006 -0400
@@ -1116,6 +1116,15 @@ static int __init early_init_dt_scan_cho
if (p != NULL && l > 0)
strlcpy(cmd_line, p, min((int)l, COMMAND_LINE_SIZE));
+ p = strstr(CONFIG_CMDLINE, "builtin=");
+
+ /* Check if we should use our builtin command line no matter what */
+ if (p) {
+ p += 8;
+ if (!strncmp(p, "override", 8))
+ l = 0;
+ }
+
#ifdef CONFIG_CMDLINE
if (l == 0 || (l == 1 && (*p) == 0))
strlcpy(cmd_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
diff -r 6f3d44537b76 arch/powerpc/kernel/prom_init.c
--- a/arch/powerpc/kernel/prom_init.c Fri Jun 16 16:07:38 2006 -0500
+++ b/arch/powerpc/kernel/prom_init.c Tue Jun 20 03:28:06 2006 -0400
@@ -575,6 +575,14 @@ static void __init early_cmdline_parse(v
if ((long)_prom->chosen > 0)
l = prom_getprop(_prom->chosen, "bootargs", p,
COMMAND_LINE_SIZE-1);
#ifdef CONFIG_CMDLINE
+ opt = strstr(RELOC(CONFIG_CMDLINE), RELOC("builtin="));
+
+ if (opt) {
+ opt += 8;
+ if (!strncmp(opt, RELOC("override"), 8))
+ l = 0; /* we want to override the firmware bootargs */
+ }
+
if (l == 0) /* dbl check */
strlcpy(RELOC(prom_cmd_line),
RELOC(CONFIG_CMDLINE), sizeof(prom_cmd_line));
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home