[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30054.1165534335@neuling.org>
Date: Fri, 08 Dec 2006 10:32:15 +1100
From: Michael Neuling <mikey@...ling.org>
To: Haren Myneni <haren@...ibm.com>
cc: vgoyal@...ibm.com, Andrew Morton <akpm@...l.org>,
Al Viro <viro@....linux.org.uk>, fastboot@...ts.osdl.org,
linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] free initrds boot option
> >Is there a kexec-tools patch too? How does second kernel know about
> >the location of the first kernel's initrd to be reused?
> >
> >
> kexec-tools has to be modified to pass the first kernel initrd. On
> powerpc, initrd locations are exported using device-tree. At present,
> kexec-tool ignores the first kernel initrd property values and creates
> new initrd properties if the user passes '--initrd' option to the kexec
> command. So, will be an issue unless first kernel device-tree is passed
> as buffer.
We've been using the --devicetreeblob kexec-tools option available for
POWERPC. This enables you to setup the device tree (and hence, the
initrd points) as you like.
I'm happy to put together a patch for kexec-tools. Unfortunately this
is arch specific. A quick look through the x86, ia64, s390 and ppc64
code shows the --initrd option for all these just reads the specified
initrd file, pushes it out to memory and uses the base and size pointers
to setup the next boot. We'd obviously just skip to the last stage.
So what's the kexec-tools option called? --initrd-location <base> <size>?
(BTW I'm offline soon, so I probably won't get to this for a few weeks)
> Initrd memory can be excluded like other segments such as RTAS and TCE
> on powerpc. However it is not implemented yet even on powerpc and is
> an issue on other archs.
The above should allow us to do these checks in kexec-tools.
Mikey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists