lkml.org 
[lkml]   [2013]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2013-03-12 10:01    [W:0.156 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site