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
> here's the processing of the parameter:
>
> ===== start
> static int __initdata do_retain_initrd;
>
> static int __init retain_initrd_param(char *str)
> {
> if (*str)
> return 0;
> do_retain_initrd = 1; <--- record the parameter
> return 1;
> }
> __setup("retain_initrd", retain_initrd_param);
> ===== end
>
> and here's the apparent effect it has, just below that in the same
> source file:
>
> ===== start
> static void __init free_initrd(void)
> {
> #ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned
> long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned
> long)__va(crashk_res.end);
> #endif
> if (do_retain_initrd)
> goto skip;
>
> ... snip for KEXEC ...
>
> free_initrd_mem(initrd_start, initrd_end);
> skip:
> initrd_start = 0;
> initrd_end = 0;
> }
> ===== end
>
> so if i read this correctly, if i use the kernel parm of
> "retain_initrd", the call to free_initrd_mem() is skipped, but the
> variables initrd_start and initrd_end are still cleared, so what
> exactly is one supposed to do with the information that the initrd
> content is still in memory?
>
> it's not like it's mounted and visible from userspace, is it? what
> is the value of that parameter?
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
> _______________________________________________
> Linux mailing list
> Linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca
> http://oclug.on.ca/mailman/listinfo/linux
--
../Randy/..