Messages in this thread | | | Date | Tue, 12 Mar 2013 09:35:41 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86, kdump: Set crashkernel_low automatically |
| |
* 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
| |