[PATCH] kexec-tools ppc64: add --reuseinitrd option

[Milton Miller]

On Apr 20, 2007, at 2:23 AM, Michael Neuling wrote:
> In message <46b0d1603ea2ab82b37daaa1888e8793 at bga.com> 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