On Sun, Jan 04, 2015 at 10:54:26AM +0800, Baoquan He wrote:
On 01/02/15 at 08:45am, Vivek Goyal wrote:
On Thu, Dec 18, 2014 at 10:34:42AM +0800, WANG Chao wrote:
[..]
I don't think it's a good idea to hard code removal of other kernel parameters which won't hurt 2nd kernel, like panic_on_warn or something like that. It's rare that one needs panic_on_warn on purpose in 2nd kernel. But we shouldn't make the assumption that no one needs it.
I think it's better to do it in our kexec-tools as a distribution specific manner.
Agreed. Distribution specific scripts should be a better place for this kind of change instead of modifying kexec-tools. kexec-tools should have no business deciding whether panic_on_warn makes sense in second kernel or not.
Yeah, most likely. But panic_on_warn is a little special then on this issue. panic_on_warn is not the stuff which doesn't hurt 2nd kernel, it surely does. I can't imagine any motivation someone expect a panic_on_warn action in kdump kernel.
I gave one corner case example where due to some bug fs corruption happens after warning if we continue. In that case panic_on_warn will make sense even in second kernel as a workaround.
Secondly, kernel will keep on introducing new command line parameters and some of them will not make sense in second kenrel. It should not be kexec-tools responsibility to figure out which of these parameters make sense and which one should be removed. It is the responsibility of distribution specific scripts.
Some of these parameters might be hidden behind CONFIG_OO option and while one distribution might have to remove it, other might not have to do the same thing (depending on whether CONFIG_FOO was enabled or not).
So I do think that kexec-tools should not get into the business of removing parameters from kernel command line. It should pass it to second kernel as passed in by user. Rest of the magic should take place in distribution specific scripts as needed.
Thanks Vivek