On Wed, 26 Sep 2012, Randy MacLeod wrote:
> On Tue, Sep 25, 2012 at 4:01 PM, Robert P. J. Day <rpjday [ at ] crashcourse [ dot ] ca> wrote:
> >
> > poking around in places in the kernel source i haven't been to in a
> > while so probably the first in a series of nitpicky questions. the
> > "retain_initrd" kernel parameter is documented thusly:
> >
> > retain_initrd [RAM] Keep initrd memory after extraction
> >
> > ok, but does that mean one has *access* to it? let's look at the
> > source in init/initramfs.c.
>
> Oh hey, there's a git history:
>
> commit 0a7b35cb18c52d651f6ed9cd59edc979200ab880
> Author: Michael Neuling <mikey [ at ] neuling [ dot ] org>
> Date: Sat Feb 10 01:44:33 2007 -0800
>
> [PATCH] Add retain_initrd boot option
>
> Add retain_initrd option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
>
> The first boot will need to hold a copy of the in memory fs for the second
> boot. This image can be large (much larger than the kernel), hence we can
> save time when the memory loader is slow. Also, it reduces the memory
> footprint while extracting the first boot since you don't need another copy
> of the fs.
> ...
>
> So that explains the intention but there's still not enough detail
> to know how to take advantage of this on a 2nd boot. I expect that
> kexec might be involved. Have you checked the lkml log?
>
> // Randy
that sort of makes sense, but it's still unclear how you would get
access to that initrd content the second time given that the kernel
code clears the initrd_start and initrd_end variables, so how would
you even know where to find it the second time?
back to research ...
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================