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:5.934 / U:0.320 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site