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
