On Apr 20, 2007, at 2:23 AM, Michael Neuling wrote:
In message <[EMAIL PROTECTED]> you wrote:
On Apr 18, 2007, at 11:29 PM, Michael Neuling wrote:
Add a --reuseinitrd option so that initrds saved using the
retain_initrd kernel option can be reused on the kexec boot.
Although this seems efficent to look at what was in the device tree,
I'd prefer we actually looked at /proc/cmdline when we parse the
arg, so that we are sure to find what the kernel is actually
using for the command line.
Besides it will be eaiser for other archs to copy the check.
Looks like we should make it a generic option. If we do, this should
probably be two patches. One to introduce the option, and one for the
ppc64 specific parts.
Do any of the other architectures allow you to see where the initrd is
located for the current boot from user space? If not, the option will
need to take two parameters saying where the retained initrd is. This
will make the option less generic (if not, we'll need to change the
other archs to export these values to user space).
Since we just added the option to the kernel, I'm guessing not.
Most of them use /proc/iomem with resources for finding system ram,
the kernel text and crash kernel region, so they should probably
add a resource there when the initrd is retained. We (powerpc) export
our bootloader data aka device tree instead, and make kexec-tools
parse it. I don't know how sparc passes an initrd to the kernel.
@@ -148,6 +154,9 @@ int elf_ppc64_load(int argc, char **argv
else
fprintf(stdout, "Warning: append= option is not passed. Using t
he
first kernel root partition\n");
+ if (ramdisk && reuse_initrd)
+ die("Can't specify --ramdisk or --initrd with --reuseinitrd\n")
;
+
This check is generic, not elf specific, so it should be where
we pass the args. Hmm, maybe this is that place and it just
wants abstracting, I don't have the tree in front of me.
I put it here so the error's caught independent of the arg parsing
order. Otherwise, we'd need to duplicate the check.
I think it's the right place, unless we move it to an arch generic
option.
I didn't mean as we parse the option, but is there not something
that gets called after we parse all the options? Maybe that is
just the load function. I was just thinking it should be in a
sanity_check_args() function that looks for exclusive options like
these rather than in "load a kernel like elf file", although that
is the only current option for ppc64, so it might be ok here.
milton
_______________________________________________
fastboot mailing list
fastboot@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/fastboot