Re: [PATCH] x86, kdump: Set crashkernel_low automatically

[Ingo Molnar <mingo@kernel.org>]

* Vivek Goyal <vgoyal@redhat.com> wrote:

> On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> > On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> > > 
> > > - Now we use dracut generated initramfs and it has been growing in 
> > >   size. Now systemd has been pulled in too.
> > 
> > And the solution to that isn't obvious?
> 
> Sorry, I did not understand what do you mean by above.
> 
> If you are suggesting that move away from dracut, it does not work in 
> practice. Initially we wrote our custom code to generate custom 
> initramfs, and we were always lagging in terms of what dump targets can 
> be supported and kept on constantly fixing the issues which had been 
> taken care of in dracut one way or other. So it was like maintaining a 
> duplicate initramfs generation tool.

The fundamental design problem is this artificial split of the kernel from 
kexec-tools, just to support an arguably exotic feature, which in turn 
then tries to support a complex compatibility matrix - making each variant 
even more super exotic. There's just not enough usage and not enough 
manpower to keep all that tidy ...

If there was tools/kexec/ then many of these constraints and quirks with 
old versions would go away: old kernels would come with old kexec tools, 
new kernels would come with new kexec tools.

Just look at how tools/perf/ is packaged up with new kernels: you 
generally get a new perf with a new kernel version. Alone this eliminates 
a fair bit of support complexity and makes it easier to keep users 
uptodate.

[ kexec tooling could go even farther: if included in the initramfs then
  it could do away with ABI constraints and compatibility expectations
  altogether.

  This is one of the cases where it _does_ make sense: kexec tools and in
  general kernel image analysis is obviously coupled to the kernel's
  current data structures. ]

If this was fixed then kexec could step a whole lot further, not just in 
terms of robustness, but also in terms of feature set - and, ultimately, 
increased usage by users and kernel developers.

Thanks,

	Ingo