Re: [RESEND PATCH v10] x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter

["H. Peter Anvin" <hpa@zytor.com>]

On 01/15/2014 10:14 AM, Vivek Goyal wrote:
> 
> For large amount of info like memory map, I agree that passing on command
> line is not a good idea. (/me taks the blame for doing that). That's why
> in new patches I want to move to pass new map on bootparams and pass
> saved_max_pfn on command line instead. This is a fresh start so we
> probably can ignore compatibility with older kernels for this new
> interface and set things right.
> 
> But for smaller options, command line seems to be good that they don't
> consume precious space in bootparams. If we introduce an option today,
> we are not sure if kdump will continue to use that option down the line
> or not. For example, few years down the line, we might be able to send
> INIT IPI to boot cpu too and not need disable_cpu_apicid. Same is the case
> with max_cpus vs nr_cpus. We used to use max_cpus=1 and now use nr_cpus=1.
> If we put all this informatoin in bootparams, they might soon become
> obsolete and keep on sitting there for eternity with no users.
> 
> Also by creating a command line, a user can use these knobs as debugging
> options and can easily test first kernel's behavior to make sure knob
> works well in first kernel before it is tested in second kernel. By making
> it part of bootparams, we have no idea whether knob works fine in first
> kernel or not.
> 
> For above reasons, I am not averse to the idea of commingling.
> 

bootparams is not a precious resource, and even if it was, you could
create your own (kexec) structure and put it in the boot_info linked
list.  bootparams is not a precious resource because is is actually
rather straightforward to extend past 4K should it become necessary; all
we really would need to do there is to include a length field in the
structure.  An auxiliary bootparams structure is also a possibility.

	-hpa