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